* Issues encountered with new Cygwin version @ 2015-09-22 23:04 Walter L. 2015-09-23 8:20 ` Andrey Repin ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Walter L. @ 2015-09-22 23:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-22 23:04 Issues encountered with new Cygwin version Walter L. @ 2015-09-23 8:20 ` Andrey Repin 2015-09-23 14:47 ` Walter L. 2015-09-24 2:26 ` Linda Walsh 2015-09-24 5:35 ` Marco Atzeri 2015-09-24 14:24 ` base-files-4.2-3 : attention maintainer Marco Atzeri 2 siblings, 2 replies; 30+ messages in thread From: Andrey Repin @ 2015-09-23 8:20 UTC (permalink / raw) To: Walter L., cygwin 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... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-23 8:20 ` Andrey Repin @ 2015-09-23 14:47 ` Walter L. 2015-09-23 16:20 ` Andrey Repin 2015-09-24 2:39 ` Linda Walsh 2015-09-24 2:26 ` Linda Walsh 1 sibling, 2 replies; 30+ messages in thread From: Walter L. @ 2015-09-23 14:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-23 14:47 ` Walter L. @ 2015-09-23 16:20 ` Andrey Repin 2015-09-24 2:39 ` Linda Walsh 1 sibling, 0 replies; 30+ messages in thread From: Andrey Repin @ 2015-09-23 16:20 UTC (permalink / raw) To: Walter L., cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-23 14:47 ` Walter L. 2015-09-23 16:20 ` Andrey Repin @ 2015-09-24 2:39 ` Linda Walsh 2015-09-24 4:34 ` Walter L. 1 sibling, 1 reply; 30+ messages in thread From: Linda Walsh @ 2015-09-24 2:39 UTC (permalink / raw) To: Walter L., cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 2:39 ` Linda Walsh @ 2015-09-24 4:34 ` Walter L. 2015-09-24 4:43 ` Linda Walsh 0 siblings, 1 reply; 30+ messages in thread From: Walter L. @ 2015-09-24 4:34 UTC (permalink / raw) To: Linda Walsh, cygwin > > > 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 4:34 ` Walter L. @ 2015-09-24 4:43 ` Linda Walsh 2015-09-24 10:35 ` Andrey Repin 2015-09-24 13:21 ` Walter L. 0 siblings, 2 replies; 30+ messages in thread From: Linda Walsh @ 2015-09-24 4:43 UTC (permalink / raw) To: Walter L.; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 4:43 ` Linda Walsh @ 2015-09-24 10:35 ` Andrey Repin 2015-09-24 13:21 ` Walter L. 1 sibling, 0 replies; 30+ messages in thread From: Andrey Repin @ 2015-09-24 10:35 UTC (permalink / raw) To: Linda Walsh, cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 4:43 ` Linda Walsh 2015-09-24 10:35 ` Andrey Repin @ 2015-09-24 13:21 ` Walter L. 2015-09-24 16:49 ` Linda Walsh 1 sibling, 1 reply; 30+ messages in thread From: Walter L. @ 2015-09-24 13:21 UTC (permalink / raw) To: Linda Walsh, cygwin > > > > > 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 13:21 ` Walter L. @ 2015-09-24 16:49 ` Linda Walsh 2015-09-24 18:35 ` Andrey Repin 2015-09-25 15:01 ` Walter L. 0 siblings, 2 replies; 30+ messages in thread From: Linda Walsh @ 2015-09-24 16:49 UTC (permalink / raw) To: Walter L., cygwin 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&pg=PA39&lpg=PA39&dq=reason+for+drivers/etc/protocol+on+windows&source=bl&hl=en&sa=X&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false#v=snippet&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 16:49 ` Linda Walsh @ 2015-09-24 18:35 ` Andrey Repin 2015-09-25 15:01 ` Walter L. 1 sibling, 0 replies; 30+ messages in thread From: Andrey Repin @ 2015-09-24 18:35 UTC (permalink / raw) To: Linda Walsh, cygwin 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&pg=PA39&lpg=PA39&dq=reason+for+drivers/etc/protocol+on+windows&source=bl&hl=en&sa=X&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false#v=snippet&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-24 16:49 ` Linda Walsh 2015-09-24 18:35 ` Andrey Repin @ 2015-09-25 15:01 ` Walter L. 2015-09-25 15:23 ` Ken Brown 2015-09-26 9:21 ` Andrey Repin 1 sibling, 2 replies; 30+ messages in thread From: Walter L. @ 2015-09-25 15:01 UTC (permalink / raw) To: cygwin 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/msg00009.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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 15:01 ` Walter L. @ 2015-09-25 15:23 ` Ken Brown 2015-09-25 16:04 ` Ken Brown 2015-09-26 9:21 ` Andrey Repin 1 sibling, 1 reply; 30+ messages in thread From: Ken Brown @ 2015-09-25 15:23 UTC (permalink / raw) To: cygwin 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/msg00009.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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 15:23 ` Ken Brown @ 2015-09-25 16:04 ` Ken Brown 2015-09-25 18:01 ` Walter L. 0 siblings, 1 reply; 30+ messages in thread From: Ken Brown @ 2015-09-25 16:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 16:04 ` Ken Brown @ 2015-09-25 18:01 ` Walter L. 2015-09-25 18:24 ` Ken Brown 0 siblings, 1 reply; 30+ messages in thread From: Walter L. @ 2015-09-25 18:01 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 18:01 ` Walter L. @ 2015-09-25 18:24 ` Ken Brown 2015-09-25 18:37 ` Walter L. 0 siblings, 1 reply; 30+ messages in thread From: Ken Brown @ 2015-09-25 18:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 18:24 ` Ken Brown @ 2015-09-25 18:37 ` Walter L. 0 siblings, 0 replies; 30+ messages in thread From: Walter L. @ 2015-09-25 18:37 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-25 15:01 ` Walter L. 2015-09-25 15:23 ` Ken Brown @ 2015-09-26 9:21 ` Andrey Repin 2015-09-26 20:26 ` Walter L. 1 sibling, 1 reply; 30+ messages in thread From: Andrey Repin @ 2015-09-26 9:21 UTC (permalink / raw) To: Walter L., cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-26 9:21 ` Andrey Repin @ 2015-09-26 20:26 ` Walter L. 2015-09-26 22:10 ` Ken Brown 0 siblings, 1 reply; 30+ messages in thread From: Walter L. @ 2015-09-26 20:26 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-26 20:26 ` Walter L. @ 2015-09-26 22:10 ` Ken Brown 2015-09-27 3:56 ` Walter L. 0 siblings, 1 reply; 30+ messages in thread From: Ken Brown @ 2015-09-26 22:10 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-26 22:10 ` Ken Brown @ 2015-09-27 3:56 ` Walter L. 2015-09-27 10:05 ` Andrey Repin 0 siblings, 1 reply; 30+ messages in thread From: Walter L. @ 2015-09-27 3:56 UTC (permalink / raw) To: cygwin, Ken Brown 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-27 3:56 ` Walter L. @ 2015-09-27 10:05 ` Andrey Repin 2015-09-27 14:45 ` Walter L. 0 siblings, 1 reply; 30+ messages in thread From: Andrey Repin @ 2015-09-27 10:05 UTC (permalink / raw) To: Walter L., cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-27 10:05 ` Andrey Repin @ 2015-09-27 14:45 ` Walter L. 0 siblings, 0 replies; 30+ messages in thread From: Walter L. @ 2015-09-27 14:45 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-23 8:20 ` Andrey Repin 2015-09-23 14:47 ` Walter L. @ 2015-09-24 2:26 ` Linda Walsh 1 sibling, 0 replies; 30+ messages in thread From: Linda Walsh @ 2015-09-24 2:26 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Issues encountered with new Cygwin version 2015-09-22 23:04 Issues encountered with new Cygwin version Walter L. 2015-09-23 8:20 ` Andrey Repin @ 2015-09-24 5:35 ` Marco Atzeri 2015-09-24 14:24 ` base-files-4.2-3 : attention maintainer Marco Atzeri 2 siblings, 0 replies; 30+ messages in thread From: Marco Atzeri @ 2015-09-24 5:35 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* base-files-4.2-3 : attention maintainer 2015-09-22 23:04 Issues encountered with new Cygwin version Walter L. 2015-09-23 8:20 ` Andrey Repin 2015-09-24 5:35 ` Marco Atzeri @ 2015-09-24 14:24 ` Marco Atzeri 2015-09-24 17:29 ` Achim Gratz 2 siblings, 1 reply; 30+ messages in thread From: Marco Atzeri @ 2015-09-24 14:24 UTC (permalink / raw) To: cygwin 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: > > 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) Corinna, the bug is in the /etc/postinstall/base-files-mketc.sh of base-files-4.2-3 -------------------------------------------- FILES="hosts protocols services networks" OSNAME="$(/usr/bin/uname -s)" WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc" [cut] for mketc in ${FILES} do if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ] then /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}" fi done -------------------------------------------- As on my systems the bug is not present, it can be a relative recent introduction. Regards Marco -- 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: base-files-4.2-3 : attention maintainer 2015-09-24 14:24 ` base-files-4.2-3 : attention maintainer Marco Atzeri @ 2015-09-24 17:29 ` Achim Gratz 2015-09-25 18:53 ` Ken Brown 0 siblings, 1 reply; 30+ messages in thread From: Achim Gratz @ 2015-09-24 17:29 UTC (permalink / raw) To: cygwin Marco Atzeri writes: > the bug is in the > /etc/postinstall/base-files-mketc.sh > of base-files-4.2-3 > > -------------------------------------------- > FILES="hosts protocols services networks" > OSNAME="$(/usr/bin/uname -s)" > WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc" > > [cut] > > for mketc in ${FILES} > do > if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ] > then > /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}" > fi > done > -------------------------------------------- > > As on my systems the bug is not present, > it can be a relative recent introduction. I've introduced this bug inadvertently when releasing base-files-4.1. I'll fix it towards the weekend. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: base-files-4.2-3 : attention maintainer 2015-09-24 17:29 ` Achim Gratz @ 2015-09-25 18:53 ` Ken Brown 2015-09-26 9:21 ` Andrey Repin 2015-09-26 9:57 ` Achim Gratz 0 siblings, 2 replies; 30+ messages in thread From: Ken Brown @ 2015-09-25 18:53 UTC (permalink / raw) To: cygwin On 9/24/2015 1:29 PM, Achim Gratz wrote: > Marco Atzeri writes: >> the bug is in the >> /etc/postinstall/base-files-mketc.sh >> of base-files-4.2-3 >> >> -------------------------------------------- >> FILES="hosts protocols services networks" >> OSNAME="$(/usr/bin/uname -s)" >> WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc" >> >> [cut] >> >> for mketc in ${FILES} >> do >> if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ] >> then >> /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}" >> fi >> done >> -------------------------------------------- >> >> As on my systems the bug is not present, >> it can be a relative recent introduction. > > I've introduced this bug inadvertently when releasing base-files-4.1. > I'll fix it towards the weekend. As long as you're updating base-files anyway, maybe you could implement one of the previously-discussed proposals for showing a prompt of "#" instead of "$" in shells with sufficient privileges. Unfortunately, I don't remember if there was ever a consensus reached on exactly how that should be done. 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: base-files-4.2-3 : attention maintainer 2015-09-25 18:53 ` Ken Brown @ 2015-09-26 9:21 ` Andrey Repin 2015-09-26 9:57 ` Achim Gratz 1 sibling, 0 replies; 30+ messages in thread From: Andrey Repin @ 2015-09-26 9:21 UTC (permalink / raw) To: Ken Brown, cygwin Greetings, Ken Brown! > As long as you're updating base-files anyway, maybe you could implement > one of the previously-discussed proposals for showing a prompt of "#" > instead of "$" in shells with sufficient privileges. Unfortunately, I > don't remember if there was ever a consensus reached on exactly how that > should be done. Something to this extent? PS1_TAIL="$( x="$" for group in $(id -G); do { test $group -eq 114 && { x="#"; break; } test $group -eq 544 && { x="#"; break; } test $group -eq 0 && { x="Please remove well-known SID overrides from your /etc/group file#"; break; } } done echo $x )" if [ "$color_prompt" = yes ]; then PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\007\]\n$PS1_TAIL ' else PS1='\u@\h:\w\007\n$PS1_TAIL ' fi unset color_prompt force_color_prompt -- With best regards, Andrey Repin Saturday, September 26, 2015 12:07:50 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: base-files-4.2-3 : attention maintainer 2015-09-25 18:53 ` Ken Brown 2015-09-26 9:21 ` Andrey Repin @ 2015-09-26 9:57 ` Achim Gratz 1 sibling, 0 replies; 30+ messages in thread From: Achim Gratz @ 2015-09-26 9:57 UTC (permalink / raw) To: cygwin Ken Brown writes: > As long as you're updating base-files anyway, maybe you could > implement one of the previously-discussed proposals for showing a > prompt of "#" instead of "$" in shells with sufficient privileges. > Unfortunately, I don't remember if there was ever a consensus reached > on exactly how that should be done. You'd need to check that group 544 is in your user token. Some folks say 114 too, but if you use cygdrop -l, this group will stay in your token, while you are _not_ having local admin rights anymore. But calling id on a domain member machine can, under unfavorable circumstances, take more than a minute to complete. The AD integration for Cygwin has developed further since I last saw this problem so it's possible it's been solved along with some other things. However since I've not had the time yet to try and re-create the setup that most consistently showed the problem I don't want to put it into any standard startup files. 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-09-27 14:45 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-22 23:04 Issues encountered with new Cygwin version Walter L. 2015-09-23 8:20 ` Andrey Repin 2015-09-23 14:47 ` Walter L. 2015-09-23 16:20 ` Andrey Repin 2015-09-24 2:39 ` Linda Walsh 2015-09-24 4:34 ` Walter L. 2015-09-24 4:43 ` Linda Walsh 2015-09-24 10:35 ` Andrey Repin 2015-09-24 13:21 ` Walter L. 2015-09-24 16:49 ` Linda Walsh 2015-09-24 18:35 ` Andrey Repin 2015-09-25 15:01 ` Walter L. 2015-09-25 15:23 ` Ken Brown 2015-09-25 16:04 ` Ken Brown 2015-09-25 18:01 ` Walter L. 2015-09-25 18:24 ` Ken Brown 2015-09-25 18:37 ` Walter L. 2015-09-26 9:21 ` Andrey Repin 2015-09-26 20:26 ` Walter L. 2015-09-26 22:10 ` Ken Brown 2015-09-27 3:56 ` Walter L. 2015-09-27 10:05 ` Andrey Repin 2015-09-27 14:45 ` Walter L. 2015-09-24 2:26 ` Linda Walsh 2015-09-24 5:35 ` Marco Atzeri 2015-09-24 14:24 ` base-files-4.2-3 : attention maintainer Marco Atzeri 2015-09-24 17:29 ` Achim Gratz 2015-09-25 18:53 ` Ken Brown 2015-09-26 9:21 ` Andrey Repin 2015-09-26 9:57 ` Achim Gratz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).