Editors set x-bit (sometimes)

Editors set x-bit (sometimes)

[Ronald Fischer]

Does anybody have an explanation for the following strange phenomenon?

When I create Ruby files (*.rb) with an, the files end up with the x-bit
set with some editors, while this does not happen with some other
editors. This is annoying, because when I use git to put the file in a
repository, and the repository is later read on Linux, the incorrect
x-bit is applied there too. The text editors where this happens, do so
consistently, as long as the file is below my Ruby HOME directory. It
does not happen, if I store the file outside my $HOME, say in c:\tmp. 

Since a few editors do not show this behaviour, one might blame the way
the editor creates the file. However, these text editors were not
written with a Cygwin environment in mind, and Windows doesn't have the
concept of an "executable bit", and it happens only if I create files
below my Cygwin Home, so I think this happens when Cygwin tries to
"infer" the x-bit from some other file properties.

I am aware that Cygwin has a policy to infer, whether the x-bit should
be set or not set. Nevertheless, this does not apply in my case:

- The files don't have a #! line
- I don't have a file association on Windows which would mark a .rb file
as being run by Ruby
- My file system is ntfs

BTW, my CYGWIN environment variable is set to just 'nodosfilewarning'.
I'm using Windows 7 and the 64-bit-version of Cygwin.

- Ronald



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Ken Brown]

On 12/13/2016 5:39 AM, Ronald Fischer wrote:
> Does anybody have an explanation for the following strange phenomenon?
>
> When I create Ruby files (*.rb) with an, the files end up with the x-bit
> set with some editors, while this does not happen with some other
> editors. This is annoying, because when I use git to put the file in a
> repository, and the repository is later read on Linux, the incorrect
> x-bit is applied there too. The text editors where this happens, do so
> consistently, as long as the file is below my Ruby HOME directory. It
> does not happen, if I store the file outside my $HOME, say in c:\tmp.
>
> Since a few editors do not show this behaviour, one might blame the way
> the editor creates the file. However, these text editors were not
> written with a Cygwin environment in mind, and Windows doesn't have the
> concept of an "executable bit", and it happens only if I create files
> below my Cygwin Home, so I think this happens when Cygwin tries to
> "infer" the x-bit from some other file properties.

Does this help?

    https://cygwin.com/faq/faq.html#faq.using.same-with-permissions

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Ronald Otto Valentin Fischer]

> Does this help?
> 
>     https://cygwin.com/faq/faq.html#faq.using.same-with-permissions

While interesting, it seems to describe a different phenomenon.
Actually, when I create files by Cygwin tools only (touch, nano, ....),
the access rights are always correct. Indeed, even after removing the
extended ACL entries - as was suggested in the FAQ -, the problem still
appears.

However, I have a new finding: When I create a file from a CMD.EXE
command line, by i.e.

    echo xx > abc.rb

the access rights *do* have the x-bits set! This is reproducible, but
only when the file which was created, is below my Cygwin tree! I agree
that this smells a lot like an extended ACL issue, but as I said, 
setacl -b provided no help.

Ronald


-- 
Ronald Fischer <ronald.fischer@fusshuhn.de>
http://www.fusshuhn.de/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Brian Inglis]

On 2016-12-13 08:20, Ronald Otto Valentin Fischer wrote:
>On 2016-12-13 10:57, Ken Brown wrote:
>> Does this help?
>>     https://cygwin.com/faq/faq.html#faq.using.same-with-permissions
> While interesting, it seems to describe a different phenomenon. 
> Actually, when I create files by Cygwin tools only (touch, nano,
> ....), the access rights are always correct. Indeed, even after
> removing the extended ACL entries - as was suggested in the FAQ -,
> the problem still appears.
> However, I have a new finding: When I create a file from a CMD.EXE 
> command line, by i.e.
>     echo xx > abc.rb
> the access rights *do* have the x-bits set! This is reproducible,
> but only when the file which was created, is below my Cygwin tree!
> I agree that this smells a lot like an extended ACL issue, but as
> I said, setacl -b provided no help.

Remove DACLs Default ACLs also on directories using: 
	setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \
			/???/**/ /???/**/* /sbin/ /sbin/*
- that takes a while to run, and you may get a few anonymous
	setfacl: Permission denied
messages - paths in the messages would have been nice here!

Be careful *NOT* to hit Windows directories including your Windows 
home directory, or any other Windows directories, native symlinks, 
native hardlinks, junctions, or file types such as Windows .lnk, 
.URL, etc. where Windows may rely on the DACLs, ACLs, and attributes 
for proper handling.

I don't know that removing them would cause problems, but I don't 
trust Windows to DTRT if it doesn't see what it expects, or DTRT in 
future if changes are made and the expected settings are not still 
in place.

-- 
-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Achim Gratz]

Brian Inglis writes:
> Remove DACLs Default ACLs also on directories using: 
> 	setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \
> 			/???/**/ /???/**/* /sbin/ /sbin/*
> - that takes a while to run, and you may get a few anonymous
> 	setfacl: Permission denied
> messages - paths in the messages would have been nice here!
>
> Be careful *NOT* to hit Windows directories including your Windows 
> home directory, or any other Windows directories, native symlinks, 
> native hardlinks, junctions, or file types such as Windows .lnk, 
> .URL, etc. where Windows may rely on the DACLs, ACLs, and attributes 
> for proper handling.

Which is why you shouldn't use the above, but have find produce a list
of the files to be changed and when you are sure it doesn't contain any
stray things process them either via the -exec + option in find or
piping into xargs (the latter is slightly less efficient and you have to
do -print0/-0, but I tend to get it right more easily then the -exec
stuff.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Henry S. Thompson]

I find I can reproduce the OP's observations, and the most recent advice
doesn't fix it (although it changes the symptoms):

From mintty/bash:

  639> cd /tmp
  641> ls -ld .
  drwxrwxr-x+ 1 ht None 0 Dec 13 19:55 ./
  640> getfacl .
  # file: .
  # owner: ht
  # group: None
  user::rwx
  group::rwx
  other:r-x
  default:user::rwx
  default:group::r-x
  default:other:r-x

  642> touch x3
  643> ls -l x3
  -rw-r--r-- 1 ht None 0 Dec 13 19:59 x3

Switch to CMD (not elevated):

  C:\Users\ht>cd ..\..\C64\tmp
  C:\C64\tmp>echo > x2
  C:\C64\tmp>

Back to mintty/bash:

  644> ls -l x2
  -rwxr-xr-x 1 ht None 13 Dec 13 20:00 x2*

OK, try the advice

  645> setfacl -bk .
  649> getfacl .
  # file: .
  # owner: ht
  # group: None
  user::rwx
  group::rwx
  other:r-x

  646> echo > y3
  647> ls -l y3
  -rw-r--r-- 1 ht None 1 Dec 13 20:01 y3

Over to CMD:

  C:\Users\ht>cd ..\..\C64\tmp
  C:\C64\tmp>echo > y2
  C:\C64\tmp>

And back to mintty/bash:

  648> ls -l y2
  -rwxrwx---+ 1 ht None 13 Dec 13 20:02 y2*
  650> ls -ld .
  drwxrwxr-x 1 ht None 0 Dec 13 20:02 ./
  652> setfacl -bk y2
  653> ls -l y2
  -rwx------ 1 ht None 13 Dec 13 20:02 y2*

Windows 10 Professional N Ver 10.0 Build 10586
 3229k 2016/08/31 C:\C64\bin\cygwin1.dll
    Cygwin DLL version info:
        DLL version: 2.6.0

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Editors set x-bit (sometimes)

[Nellis, Kenneth]

> From: Achim Gratz 
> .. the latter is slightly less efficient and you have to
> do -print0/-0, but I tend to get it right more easily then the -exec
> stuff.

Really? I always thought the opposite. With -exec, doesn't
find invoke the command for each single found object? While xargs 
allows a single command to operate on a whole slew of objects.

For example:
find ... -exec pgm {} \;
executes pgm separately for each found object while
find ... | xargs pgm
invokes pgm only once for as many files as will fit on the 
command line, which is quite a few.

If I'm wrong about this, please share.

Or, perhaps we are talking about commands that only take
a single object. In that case, you would need to say
xargs -n1
in which case, I agree, it is less efficient.

--Ken Nellis

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Andrey Repin]

Greetings, Nellis, Kenneth!

>> From: Achim Gratz 
>> .. the latter is slightly less efficient and you have to
>> do -print0/-0, but I tend to get it right more easily then the -exec
>> stuff.

> Really? I always thought the opposite. With -exec, doesn't
> find invoke the command for each single found object?

Depends, how do you set the find, and what the net effect you wan to achieve.

> While xargs allows a single command to operate on a whole slew of objects.

Which boils down to executing command every time for each argument.

> For example:
> find ... -exec pgm {} \;
> executes pgm separately for each found object

What about

  find ... -exec pgm '{}' +

?

> while
> find ... | xargs pgm
> invokes pgm only once for as many files as will fit on the
> command line, which is quite a few.

> If I'm wrong about this, please share.

It really depends on what you are doing with find.

find . -iname *.php -execdir grep -qP '(?<=function )funcname' '{}' \; -print

is one thing, but

find . -date +7 -exec mv -t /dir '{}' +

is completely another.

> Or, perhaps we are talking about commands that only take
> a single object. In that case, you would need to say
> xargs -n1
> in which case, I agree, it is less efficient.


-- 
With best regards,
Andrey Repin
Wednesday, December 14, 2016 20:13:08

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Editors set x-bit (sometimes)

[Achim Gratz]

Nellis, Kenneth writes:
> Really? I always thought the opposite. With -exec, doesn't
> find invoke the command for each single found object? While xargs 
> allows a single command to operate on a whole slew of objects.

I said "-exec +", although I concur it was too easy to miss.

> For example:
> find ... -exec pgm {} \;

Try replacing the "\;" with "+", depending on whether pgm can deal with
multiple arguments.

> executes pgm separately for each found object while
> find ... | xargs pgm
> invokes pgm only once for as many files as will fit on the 
> command line, which is quite a few.

Which is what

find ... -exec pgm {} +

will do, without piping the data to xarg and without you having to
remember that you really, really wanted to say

find … -print0 | xargs -0 pgm

unless you already know that there are no spaces or funny characters
anywhere in your filenames.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Editors set x-bit (sometimes)

[Nellis, Kenneth]

From: Achim Gratz 
> I said "-exec +", although I concur it was too easy to miss.

Indeed, I overlooked the "+" and was unfamiliar with that option
to find. Glad I asked. Learned something today. Thanx for the 
clarification. ☺

--Ken Nellis

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple