Re: Issues encountered with new Cygwin version
On 9/27/2015 5:54 AM, Andrey Repin wrote: Greetings, Walter L.! My question was merely based on Andrey's statement that "This is configurable" (see above); I don't know what he meant and what "this" is, Git or Cygwin. "This" being "Git", and http://cygwin.com/ml/cygwin/2015-09/msg00072.html If by saying "This is configurable" he meant running 'setfacl -b' on the top-level directory, then I simply misunderstood his statement; I was just misinterpreting "configurable" meaning setting "noacl" or something like that to the file system or the environment. The problem child here is Git that bindly assumes that there's no other permissions than POSIX permissions, and no other executables than POSIX executables. Both statements aren't true for any given OS these days. Since there are usually more than one way to do something, I was just wondering if Andrey knew of another way to handle the permission issue by the way of some configuration setting. I didn't, but I'm reading the list patiently, picking knowledge where I can. Thanks to Adam. This solution came up relatively recently. Thanks for the clarification and the link, Andrey; it certainly gives me a better picture of what's going on. Unfortunately, per my previous email, configuring Git with "core.fileMode=false" won't help me because I still want to enforce file permissions and not ignore it. Other developers sometimes inadvertently set the wrong permission on some files and I want to be able to revert them to the correct permission upon my next commit of the files. Calling 'setfacl -b' on the parent folder containing the project suggested by Ken may be the best course of action until Git changes its behavior. Thanks again to both of you for the depth of information provided. Regards, ~WL -- 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: Issues encountered with new Cygwin version
Greetings, Walter L.! > My question was merely based on Andrey's statement that "This is > configurable" (see above); I don't know what he meant and what "this" is, > Git or Cygwin. "This" being "Git", and http://cygwin.com/ml/cygwin/2015-09/msg00072.html > If by saying "This is configurable" he meant running > 'setfacl -b' on the top-level directory, then I simply misunderstood his > statement; I was just misinterpreting "configurable" meaning setting "noacl" > or something like that to the file system or the environment. The problem child here is Git that bindly assumes that there's no other permissions than POSIX permissions, and no other executables than POSIX executables. Both statements aren't true for any given OS these days. > Since there are usually more than one way to do something, I was just > wondering if Andrey knew of another way to handle the permission issue by > the way of some configuration setting. I didn't, but I'm reading the list patiently, picking knowledge where I can. Thanks to Adam. This solution came up relatively recently. -- With best regards, Andrey Repin Sunday, September 27, 2015 12:48:33 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: Issues encountered with new Cygwin version
Greetings, Walter L.! > This is very unfortunate because I'm using Git in Cygwin specifically > because it doesn't set the executable bit like Windows applications. This is, you know, configurable?... -- With best regards, Andrey Repin Saturday, September 26, 2015 12:04:24 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: Issues encountered with new Cygwin version
On 9/26/2015 4:26 PM, Walter L. wrote: On 9/26/2015 5:05 AM, Andrey Repin wrote: Greetings, Walter L.! > This is very unfortunate because I'm using Git in Cygwin specifically > because it doesn't set the executable bit like Windows applications. This is, you know, configurable?... Which part? Git or Cygwin? You mean I can configre Cygwin to prevent Git from creating files that inherit the executable bit from the ACL? I don't mean to be nit-picking, but the way you phrased this questions suggests that you have some misconceptions about what's going on here. There are two separate issues: 1. Starting with Cygwin 1.7.34, the "group permissions" of a file reflect not only the permissions of the primary group of the file, but also all secondary user and group entries in the file's ACL. This is explained in https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working in the context of ssh, but it applies equally well to your situation. So if you're seeing an unexpected executable permission, it's because the file has an ACL entry giving executable permission to some user or group other than the primary ones. You can see these ACL entries by running getfacl on the file. A typical example is "group:Administrators:rwx", which occurred in some of the ACLs in my earlier email. 2. If the directory has *default* ACL entries, then these entries, by default, will be inherited by files created in that directory (by Git or any other application). Looking at my earlier email again, you'll see some directories with ACL entries "default:group:Administrators:rwx", causing the entry "group:Administrators:rwx" to be inherited by files created in those directories. As explained above, this causes rwx permissions to show up as "group permissions" of the file. In your situation, you are working in a directory that, for whatever reason, contains such default ACL entries. If you don't want files created in that directory to inherit the corresponding entries, then you need to get rid of those unwanted default ACL entries. The simplest way is to run 'setfacl -b' on the directory, as explained in the FAQ cited above and in my earlier email. None of this is special to Git or to executable permission. 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: Issues encountered with new Cygwin version
On 9/26/2015 6:10 PM, Ken Brown wrote: > On 9/26/2015 5:05 AM, Andrey Repin wrote: > > > Greetings, Walter L.! > > > > > This is very unfortunate because I'm using Git in Cygwin > > > specifically because it doesn't set the executable bit like Windows > > > applications. > > > > This is, you know, configurable?... > > Which part? Git or Cygwin? You mean I can configre Cygwin to prevent Git > from creating files that inherit the executable bit from the ACL? I don't mean to be nit-picking, but the way you phrased this questions suggests that you have some misconceptions about what's going on here. No. There's no misconception here. I understood perfectly well from the explanation in your last email. 1. Starting with Cygwin 1.7.34, the "group permissions" of a file reflect not only the permissions of the primary group of the file, but also all secondary user and group entries in the file's ACL. So if you're seeing an unexpected executable permission, it's because the file has an ACL entry giving executable permission to some user or group other than the primary ones. You can see these ACL entries by running getfacl on the file. Thanks Ken. I get that. 2. If the directory has *default* ACL entries, then these entries, by default, will be inherited by files created in that directory (by Git or any other application). If you don't want files created in that directory to inherit the corresponding entries, then you need to get rid of those unwanted default ACL entries. The simplest way is to run 'setfacl -b' on the directory, as explained in the FAQ cited above and in my earlier email. Thanks again... I get that as well, and I've went ahead and ran 'setfacl -b' on a top-level directory that contains all my projects per your suggestion from the previous email. All is well. My question was merely based on Andrey's statement that "This is configurable" (see above); I don't know what he meant and what "this" is, Git or Cygwin. If by saying "This is configurable" he meant running 'setfacl -b' on the top-level directory, then I simply misunderstood his statement; I was just misinterpreting "configurable" meaning setting "noacl" or something like that to the file system or the environment. Since there are usually more than one way to do something, I was just wondering if Andrey knew of another way to handle the permission issue by the way of some configuration setting. Regards, ~WL -- 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: Issues encountered with new Cygwin version
On 9/26/2015 5:05 AM, Andrey Repin wrote: Greetings, Walter L.! > This is very unfortunate because I'm using Git in Cygwin specifically > because it doesn't set the executable bit like Windows applications. This is, you know, configurable?... Which part? Git or Cygwin? You mean I can configre Cygwin to prevent Git from creating files that inherit the executable bit from the ACL? Thanks, ~WL -- 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: Issues encountered with new Cygwin version
On 24/09/2015 07:35, Marco Atzeri wrote: > 2) The 'touch' command creates a file with the executable bit set > > [user@hostname ~]$ touch newfile.txt > [user@hostname ~]$ ls -l newfile.txt > -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt It likely depends on the inherited permissions from the directory BINGO! Looks like starting 1.7.34 the file permissions were "fixed" to exhibit this new behavior (https://www.cygwin.com/ml/cygwin-announce/2015-02/msg9.html). After reverting back to 1.7.33 I was able to get the previous behavior back. This is very unfortunate because I'm using Git in Cygwin specifically because it doesn't set the executable bit like Windows applications. With this new behavior, trying to rebase or cherry-pick causes merge conflicts because any file touched by Git will have the executable bit set. Additionally, trying to do a 'reset --hard' doesn't work anymore since the executable bit stays on with the new file permission behavior, so you'll never really return to the previous state. Yes, I can always set 'filemode=false' to ignore file permissions, but I still want to be able to enforce the correct file mode upon commits. Suggestions? Regards, ~WL -- 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: Issues encountered with new Cygwin version
On 9/25/2015 11:01 AM, Walter L. wrote: On 24/09/2015 07:35, Marco Atzeri wrote: > 2) The 'touch' command creates a file with the executable bit set > > [user@hostname ~]$ touch newfile.txt > [user@hostname ~]$ ls -l newfile.txt > -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt It likely depends on the inherited permissions from the directory BINGO! Looks like starting 1.7.34 the file permissions were "fixed" to exhibit this new behavior (https://www.cygwin.com/ml/cygwin-announce/2015-02/msg9.html). After reverting back to 1.7.33 I was able to get the previous behavior back. This is very unfortunate because I'm using Git in Cygwin specifically because it doesn't set the executable bit like Windows applications. With this new behavior, trying to rebase or cherry-pick causes merge conflicts because any file touched by Git will have the executable bit set. Additionally, trying to do a 'reset --hard' doesn't work anymore since the executable bit stays on with the new file permission behavior, so you'll never really return to the previous state. Yes, I can always set 'filemode=false' to ignore file permissions, but I still want to be able to enforce the correct file mode upon commits. Suggestions? I think you misunderstood what Marco was saying. If the problem is caused by the default ACL on the directory, you could fix that ACL. 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: Issues encountered with new Cygwin version
On 9/25/2015 11:23 AM, Ken Brown wrote: I think you misunderstood what Marco was saying. If the problem is caused by the default ACL on the directory, you could fix that ACL. To elaborate on this, observe the following: $ cd /cygdrive/c/Users/kbrown/AppData/Local/Temp $ getfacl . # file: . # owner: kbrown # group: SYSTEM user::rwx group::rwx group:Administrators:rwx mask:rwx other:--- default:user::rwx default:user:kbrown:rwx default:group::rwx default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:rwx default:other:--- $ mkdir foo $ getfacl foo # file: foo # owner: kbrown # group: None user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:rwx default:other:r-x $ cd foo $ touch bar $ getfacl bar # file: bar # owner: kbrown # group: None user::rw- group::r-- group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:r-- $ ls -l bar -rw-rwxr--+ 1 kbrown None 0 2015-09-25 11:56 bar* $ setfacl -b . $ getfacl . # file: . # owner: kbrown # group: None user::rwx group::r-x other:r-x default:user::rwx default:group::r-x default:other:r-x $ touch baz $ getfacl baz # file: baz # owner: kbrown # group: None user::rw- group::r-- other:r-- $ ls -l baz -rw-r--r-- 1 kbrown None 0 2015-09-25 11:57 baz 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: Issues encountered with new Cygwin version
On 9/25/2015 2:01 PM, Walter L. wrote: On 9/25/2015 12:04 PM, Ken Brown wrote: > I think you misunderstood what Marco was saying. If the problem is > caused by the default ACL on the directory, you could fix that ACL. To elaborate on this, observe the following: Hi Ken, thanks for the clarification. I understood what Marco meant and your examples. I was just saying that the new (correct?) behavior of inheriting the ACL from the parent folder for newly created file has the side effect of causing Git to behave differently from before. I suppose the point you're making (based on your example) is that I should just remove the ACL from the parent folder if I don't want new files in the folder to inherit the executable bit. If that's the case then I guess I'll need to do that anytime I clone a new project. Why not just run 'setfacl -b' once and for all on whatever directory you do your work in? Is it under your home directory? Do you have default ACL entries on your home directory that are then inherited by every subdirectory you create? 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: Issues encountered with new Cygwin version
On 9/25/2015 2:24 PM, Ken Brown wrote: Why not just run 'setfacl -b' once and for all on whatever directory you do your work in? Is it under your home directory? Do you have default ACL entries on your home directory that are then inherited by every subdirectory you create? Ken Actually yes, that's another approach I can take - i.e. just remove the ACL from the directory containing all the projects. Hopefully that'll take care of everything else. Thanks. ~WL -- 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: Issues encountered with new Cygwin version
On 9/25/2015 12:04 PM, Ken Brown wrote: > I think you misunderstood what Marco was saying. If the problem is > caused by the default ACL on the directory, you could fix that ACL. To elaborate on this, observe the following: Hi Ken, thanks for the clarification. I understood what Marco meant and your examples. I was just saying that the new (correct?) behavior of inheriting the ACL from the parent folder for newly created file has the side effect of causing Git to behave differently from before. I suppose the point you're making (based on your example) is that I should just remove the ACL from the parent folder if I don't want new files in the folder to inherit the executable bit. If that's the case then I guess I'll need to do that anytime I clone a new project. Regards, ~WL -- 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: Issues encountered with new Cygwin version
Greetings, Linda Walsh! >>> > > I believe the target of the symlink should be "protocol" (i.e. >>> > > singular) >>> > >>> > Err. That is. How did no one found it earlier? >>> --- >>> Because it is plural on unix/linux? MS seems to have misspelt it? >> >> I believe it's "misspelt" due to the 8 character limit for legacy file >> names, > --- > How would that affect 'services'? It doesn't. -- With best regards, Andrey Repin Thursday, September 24, 2015 13:29:32 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: Issues encountered with new Cygwin version
> > > > I believe the target of the symlink should be "protocol" (i.e. > > > > singular) > > > > > > Err. That is. How did no one found it earlier? > > --- > > Because it is plural on unix/linux? MS seems to have misspelt it? > > I believe it's "misspelt" due to the 8 character limit for legacy file > names, --- How would that affect 'services'? Sorry, you lost me. 'services' has 8 characters in the file name and so is its symlink target; That shouldn't be an issue. Of the 4 symlinks under /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' exceeds the 8 character limit and hence the actual target file in Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the *target* file not the symlinks themselves, which are fine. ~WL -- 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: Issues encountered with new Cygwin version
Greetings, Linda Walsh! >>> > > > > I believe the target of the symlink should be "protocol" (i.e. >>> How would that affect 'services'? >> >> Sorry, you lost me. 'services' has 8 characters in the file name and so is >> its symlink target; That shouldn't be an issue. Of the 4 symlinks under >> /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' >> exceeds the 8 character limit and hence the actual target file in >> Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the >> *target* file not the symlinks themselves, which are fine. > --- > Oops.. my bad -- don't know why I substituted services. However, > weren't those files there for unix-subsystem support? Not sure: > From this: > https://books.google.com/books?id=6hlNFc7drzEC=PA39=PA39=reason+for+drivers/etc/protocol+on+windows=bl=en=X=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false#v=snippet=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false > (page 39) -- it says those files were specific to NT systems beginning with > NT4.0, which used NTFS. I don't know if NT supported having the > windows/system32 > directory on FAT][32]... It did. Read the help article about "convert" tool for more info. > NT4 would have been the version before Windows 2000 Aye. -- With best regards, Andrey Repin Thursday, September 24, 2015 21:32: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: Issues encountered with new Cygwin version
Walter L. wrote: > > > > I believe the target of the symlink should be "protocol" (i.e. How would that affect 'services'? Sorry, you lost me. 'services' has 8 characters in the file name and so is its symlink target; That shouldn't be an issue. Of the 4 symlinks under /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' exceeds the 8 character limit and hence the actual target file in Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the *target* file not the symlinks themselves, which are fine. --- Oops.. my bad -- don't know why I substituted services. However, weren't those files there for unix-subsystem support? Not sure: From this: https://books.google.com/books?id=6hlNFc7drzEC=PA39=PA39=reason+for+drivers/etc/protocol+on+windows=bl=en=X=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false#v=snippet=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false (page 39) -- it says those files were specific to NT systems beginning with NT4.0, which used NTFS. I don't know if NT supported having the windows/system32 directory on FAT][32]... NT4 would have been the version before Windows 2000 -- 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: Issues encountered with new Cygwin version
Thanks for the quick response! > 2) The 'touch' command creates a file with the executable bit set > [user@hostname ~]$ touch newfile.txt > [user@hostname ~]$ ls -l newfile.txt > -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt > I am fully aware that Windows programs (e.g. Eclipse and Windows > Explorer) will create files with the executable bit set due to ACL and > NTFS permissions. However, if I 'touch' a file inside an earlier version > of Cygwin Define "earlier" ? The permissions handling has been extensively rewritten since 1.7.34. Probably from a few months ago, but I can't confirm. I've been trying to figure out how to revert back to an earlier version to verify this. Where can I find archived versions of Cygwin? > the file would be created without the executable bit set (i.e. 644). Which will then prevent opening it from Explorer by file association. Not really... In the above example if I 'chmod 644 newfile.txt' in Cygwin, Windows can still open up the file in notepad by just double-clicking on the file. Checking the file permission under Windows shows "Special permissions" checked. It also works even if I remove the ACL bit shown below: [user@hostname ~]$ chmod 644 newfile.txt [user@hostname ~]$ ls -l newfile.txt -rw-r--r--+ 1 user Domain Users 0 Sep 23 10:30 newfile.txt [user@hostname ~]$ setfacl -b newfile.txt [user@hostname ~]$ ls -l newfile.txt -rw-r--r-- 1 user Domain Users 0 Sep 23 10:30 newfile.txt At this point I double-clicked on the file in Explorer and it opened in Notepad, which I then added a line of text and saved it. [user@hostname ~]$ ls -l newfile.txt -rw-r--r-- 1 user Domain Users 18 Sep 23 10:32 newfile.txt [user@hostname ~]$ cat newfile.txt this is a new file [user@hostname ~]$ > To be honest, I can't tell if this is caused by the new version of > Cygwin or a Windows Update. Likely it is caused by the change in Cygwin permissions handling. It now correctly inherit permissions in most cases. > [user@hostname ~]$ uname -a > CYGWIN_NT-6.1-WOW hostname 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin Regards, ~WL -- 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: Issues encountered with new Cygwin version
Greetings, Walter L.! > Thanks for the quick response! >> > 2) The 'touch' command creates a file with the executable bit set >> >> > [user@hostname ~]$ touch newfile.txt >> > [user@hostname ~]$ ls -l newfile.txt >> > -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt >> >> > I am fully aware that Windows programs (e.g. Eclipse and Windows >> > Explorer) will create files with the executable bit set due to ACL and >> > NTFS permissions. However, if I 'touch' a file inside an earlier version >> > of Cygwin >> >> Define "earlier" ? The permissions handling has been extensively rewritten >> since 1.7.34. > Probably from a few months ago, but I can't confirm. I've been trying to > figure out how to revert back to an earlier version to verify this. Where > can I find archived versions of Cygwin? Check "Cygwin Time Machine". You'd need a separate install for that, though, to space out possible package conflicts. -- With best regards, Andrey Repin Wednesday, September 23, 2015 19:07:44 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: Issues encountered with new Cygwin version
Greetings, Walter L.! > I've just performed a fresh install of the latest (2.2.1) Cygwin on 64-bit > Windows 7 and noticed 2 issues with the new version that I'd like to verify > whether or not they are bugs: > 1) The symlink to protocol file seems incorrect > [user@hostname /etc]$ ls -l | grep protocol > lrwxrwxrwx 1 user Domain Users 50 Sep 22 17:03 protocols -> > /cygdrive/c/Windows/System32/drivers/etc/protocols > [user@hostname /etc]$ ls -l /cygdrive/c/Windows/System32/drivers/etc | grep > protocol > -rwxrwx---+ 1 SYSTEM SYSTEM 1358 Jun 10 2009 protocol > I believe the target of the symlink should be "protocol" (i.e. singular) Err. That is. How did no one found it earlier? > 2) The 'touch' command creates a file with the executable bit set > [user@hostname ~]$ touch newfile.txt > [user@hostname ~]$ ls -l newfile.txt > -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt > I am fully aware that Windows programs (e.g. Eclipse and Windows Explorer) > will create files with the executable bit set due to ACL and NTFS > permissions. However, if I 'touch' a file inside an earlier version of > Cygwin Define "earlier" ? The permissions handling has been extensively rewritten since 1.7.34. > the file would be created without the executable bit set (i.e. 644). Which will then prevent opening it from Explorer by file association. > To be honest, I can't tell if this is caused by the new version of Cygwin or > a Windows Update. Likely it is caused by the change in Cygwin permissions handling. It now correctly inherit permissions in most cases. > [user@hostname ~]$ uname -a > CYGWIN_NT-6.1-WOW hostname 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin -- With best regards, Andrey Repin Wednesday, September 23, 2015 11:12:34 Sorry for my terrible english...
Re: Issues encountered with new Cygwin version
> > I believe the target of the symlink should be "protocol" (i.e. > > singular) > > Err. That is. How did no one found it earlier? --- Because it is plural on unix/linux? MS seems to have misspelt it? I believe it's "misspelt" due to the 8 character limit for legacy file names, and the weird thing is the script (http://sourceware.org/ml/cygwin/2002-09/msg00590.html) should already be handling it; Something must've changed in the script, and I don't even know where to find the change log for the script. Regards, ~WL -- 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: Issues encountered with new Cygwin version
Andrey Repin wrote: I believe the target of the symlink should be "protocol" (i.e. singular) Err. That is. How did no one found it earlier? --- Because it is plural on unix/linux? MS seems to have misspelt it? -- 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: Issues encountered with new Cygwin version
Walter L. wrote: Define "earlier" ? The permissions handling has been extensively rewritten since 1.7.34. Probably from a few months ago, but I can't confirm. I've been trying to figure out how to revert back to an earlier version to verify this. Where can I find archived versions of Cygwin? --- Yeah... I hear that... am more than a little afraid to update my cygwin to 2.x for fear of some icky breakage...(i.e. my groups/users, mostly work using my Linux server as a NT4-level domain server/file server. Am afraid new security will in some way break things... Already -- cygwin has broken NT-mount points created with linkd and ship a broken version of 'login' that doesn't honor the "-p" switch resulting in the need for insecure workarounds. Will likely upgrade at some point, but am not looking forward to it. -- 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: Issues encountered with new Cygwin version
Walter L. wrote: > > I believe the target of the symlink should be "protocol" (i.e. > > singular) > > Err. That is. How did no one found it earlier? --- Because it is plural on unix/linux? MS seems to have misspelt it? I believe it's "misspelt" due to the 8 character limit for legacy file names, --- How would that affect 'services'? -- 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: Issues encountered with new Cygwin version
On 23/09/2015 01:04, Walter L. wrote: Hi, I've just performed a fresh install of the latest (2.2.1) Cygwin on 64-bit Windows 7 and noticed 2 issues with the new version that I'd like to verify whether or not they are bugs: 2) The 'touch' command creates a file with the executable bit set [user@hostname ~]$ touch newfile.txt [user@hostname ~]$ ls -l newfile.txt -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt I am fully aware that Windows programs (e.g. Eclipse and Windows Explorer) will create files with the executable bit set due to ACL and NTFS permissions. However, if I 'touch' a file inside an earlier version of Cygwin the file would be created without the executable bit set (i.e. 644). To be honest, I can't tell if this is caused by the new version of Cygwin or a Windows Update. [user@hostname ~]$ uname -a CYGWIN_NT-6.1-WOW hostname 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin This is my first time posting, so please let me know if I need to provide additional information, or if I should split this into 2 separate topics. Thanks, ~WL It likely depends on the inherited permissions from the directory $ cd /tmp /tmp $ touch prova $ ls -l prova -rw-r--r-- 1 marco Administrators 0 Sep 24 07:27 prova $ getfacl prova # file: prova # owner: marco # group: Administrators user::rw- group::r-- other:r-- $ cd /cygdrive/e/temp $ touch prova $ ls -l prova -rw-rwxr--+ 1 marco Administrators 0 Sep 24 07:27 prova* $ getfacl prova # file: prova # owner: marco # group: Administrators user::rw- group::r-- group:SYSTEM:rwx mask:rwx other:r-- -- 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
Issues encountered with new Cygwin version
Hi, I've just performed a fresh install of the latest (2.2.1) Cygwin on 64-bit Windows 7 and noticed 2 issues with the new version that I'd like to verify whether or not they are bugs: 1) The symlink to protocol file seems incorrect [user@hostname /etc]$ ls -l | grep protocol lrwxrwxrwx 1 user Domain Users 50 Sep 22 17:03 protocols -> /cygdrive/c/Windows/System32/drivers/etc/protocols [user@hostname /etc]$ ls -l /cygdrive/c/Windows/System32/drivers/etc | grep protocol -rwxrwx---+ 1 SYSTEM SYSTEM 1358 Jun 10 2009 protocol I believe the target of the symlink should be "protocol" (i.e. singular) 2) The 'touch' command creates a file with the executable bit set [user@hostname ~]$ touch newfile.txt [user@hostname ~]$ ls -l newfile.txt -rwxrwx---+ 1 user Domain Users 0 Sep 22 17:21 newfile.txt I am fully aware that Windows programs (e.g. Eclipse and Windows Explorer) will create files with the executable bit set due to ACL and NTFS permissions. However, if I 'touch' a file inside an earlier version of Cygwin the file would be created without the executable bit set (i.e. 644). To be honest, I can't tell if this is caused by the new version of Cygwin or a Windows Update. [user@hostname ~]$ uname -a CYGWIN_NT-6.1-WOW hostname 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin This is my first time posting, so please let me know if I need to provide additional information, or if I should split this into 2 separate topics. Thanks, ~WL -- 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
