Issues encountered with new Cygwin version

Issues encountered with new Cygwin version

[Walter L.]

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

Re: Issues encountered with new Cygwin version

[Andrey Repin]

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

[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?

> > 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

[Andrey Repin]

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

[Linda Walsh]

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

[Linda Walsh]

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.]

> > > 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

[Linda Walsh]

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

[Marco Atzeri]

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

Re: Issues encountered with new Cygwin version

[Andrey Repin]

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

[Walter L.]

> > > > > 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

base-files-4.2-3 : attention maintainer

[Marco Atzeri]

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

Re: Issues encountered with new Cygwin version

[Linda Walsh]

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

Re: base-files-4.2-3 : attention maintainer

[Achim Gratz]

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

Re: Issues encountered with new Cygwin version

[Andrey Repin]

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

Re: Issues encountered with new Cygwin version

[Walter L.]

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

Re: Issues encountered with new Cygwin version

[Ken Brown]

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

Re: Issues encountered with new Cygwin version

[Ken Brown]

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

[Walter L.]

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

[Ken Brown]

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

[Walter L.]

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: base-files-4.2-3 : attention maintainer

[Ken Brown]

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

Re: Issues encountered with new Cygwin version

[Andrey Repin]

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: base-files-4.2-3 : attention maintainer

[Andrey Repin]

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

Re: base-files-4.2-3 : attention maintainer

[Achim Gratz]

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

Re: Issues encountered with new Cygwin version

[Walter L.]

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

[Ken Brown]

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

[Walter L.]

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

[Andrey Repin]

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

[Walter L.]

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