Possible chmod problem with a path

Possible chmod problem with a path

[Phil Smith]

The short description is that chmod *with a path* says it works, but doesn't. If I cd to the directory and do it from there, it works. 

This behavior *seems* to have started recently, after I installed gawk (and in the process updated some other Cygwin bits). Our scaffolding for some cross-platform builds uses Cygwin (and CMake), and I started having permissions problems with the build artifacts on my machine.

I've tried with both forward and backslashes. In the examples below, the path is longish, but I can reproduce it to C:\temp as well. A colleague with an older Cygwin cannot reproduce it. Of course it's possible this is Windows somehow having become confused, but it's hard to see how (but then, it's Windows...OK, I'm looping).

I've read the FAQ and searched the archives as best I can -- there are lots of hits for "chmod" and "path", of course.

Any suggestions (besides "reformat and reinstall Windows") welcome.

Environment:
Windows 7 Professional, fully patched, 64-bit, Genuine Intel.

uname -r 1.7.35(0.287/5/3)

Asterisked lines are my comments:

* OK, I'm in C:\SVN\zFPE610:
C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1
cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied

* Let's chmod:
C:\SVN\zFPE610>chmod -v 777 C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/*
mode of 'C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1' changed from 0644 (rw-r--r--) to 0777 (rwxrwxrwx)

* Nope:
C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1
cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied

* Let's look:
C:\SVN\zFPE610>ls -l ZFP-BUILD-2015-03-27-001/Updated/*
----rwx---+ 1 phsiii None 6800 Mar 27 15:24 ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1

* That sneaky chmod lied!

* Let's go to the directory:
C:\SVN\zFPE610>cd C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/

* Nope, as expected:
C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1
cat: VSHPCRT1: Permission denied

* Now let's chmod again from there:
C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>chmod 777 *

* Hey, it works!
C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1
¦Q¦@@X¦¦^G¦¦b¦¦¦¦¦¦¦¦¦¦a¦¦a¦¦¦¦K¦¦@@@Ö¦¦¦¦¦¦¦@¦¦¦¦`¦¦¦¦¦¦¦¦¦¦¦¦¦¦@@¦8@@¦8@@

--
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: Possible chmod problem with a path

[Andrey Repin]

Greetings, Phil Smith!

> The short description is that chmod *with a path* says it works, but
> doesn't. If I cd to the directory and do it from there, it works. 

> This behavior *seems* to have started recently, after I installed gawk (and
> in the process updated some other Cygwin bits). Our scaffolding for some
> cross-platform builds uses Cygwin (and CMake), and I started having
> permissions problems with the build artifacts on my machine.

> I've tried with both forward and backslashes. In the examples below, the
> path is longish, but I can reproduce it to C:\temp as well. A colleague with
> an older Cygwin cannot reproduce it. Of course it's possible this is Windows
> somehow having become confused, but it's hard to see how (but then, it's Windows...OK, I'm looping).

> I've read the FAQ and searched the archives as best I can -- there are lots
> of hits for "chmod" and "path", of course.

> Any suggestions (besides "reformat and reinstall Windows") welcome.

> Environment:
> Windows 7 Professional, fully patched, 64-bit, Genuine Intel.

> uname -r 1.7.35(0.287/5/3)

> Asterisked lines are my comments:

> * OK, I'm in C:\SVN\zFPE610:
> C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1
> cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied

> * Let's chmod:
> C:\SVN\zFPE610>chmod -v 777 C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/*
> mode of 'C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1' changed
> from 0644 (rw-r--r--) to 0777 (rwxrwxrwx)

Please use Cygwin paths with Cygwin tools.
Windows paths are not guaranteed to work with every Cygwin tool.

> * Nope:
> C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1
> cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied

> * Let's look:
> C:\SVN\zFPE610>ls -l ZFP-BUILD-2015-03-27-001/Updated/*
> ----rwx---+ 1 phsiii None 6800 Mar 27 15:24
> ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1

> * That sneaky chmod lied!

> * Let's go to the directory:
> C:\SVN\zFPE610>cd C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/

> * Nope, as expected:
> C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1
> cat: VSHPCRT1: Permission denied

> * Now let's chmod again from there:
> C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>chmod 777 *

> * Hey, it works!
> C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1
> ¦Q¦@@X¦¦^G¦¦b¦¦¦¦¦¦¦¦¦¦a¦¦a¦¦¦¦K¦¦@@@Ö¦¦¦¦¦¦¦@¦¦¦¦`¦¦¦¦¦¦¦¦¦¦¦¦¦¦@@¦8@@¦8@@

What you are doing may or may not work, depends, if you are using Cygwin or
native Subversion client.
In either case, it isn't very bright idea to enforce POSIX access mask outside
Cygwin tree, unless you know what you are doing and absolutely need it.
From your description, you don't need it at all.


-- 
With best regards,
Andrey Repin
Monday, March 30, 2015 17:16:28

Sorry for my terrible english...

RE: Possible chmod problem with a path [WARNING: SPF validation failed]

[Phil Smith]

Thanks for the reply. Some thoughts:

>Please use Cygwin paths with Cygwin tools.
>Windows paths are not guaranteed to work with every Cygwin tool.

This is scripted, and while I can hack it to use Cygwin paths, it probably shouldn't be lying to me, saying that it worked. And it did work before, still does with older Cygwin (on another machine).

>What you are doing may or may not work, depends, if you are using Cygwin or
>native Subversion client.
>In either case, it isn't very bright idea to enforce POSIX access mask outside
>Cygwin tree, unless you know what you are doing and absolutely need it.
From your description, you don't need it at all.

I'm not actually trying to enforce POSIX anything--I'm trying to be able to read the build artifacts, which were put there via mv and cp. The compiler is native Windows, isn't creating the artifacts with any special permissions. So there's actually another mystery, which is why the artifacts don't have the right permissions in the first place. With the cobbled-together environment (CMake, the Dignus compiler, Cygwin) this may not be really diagnosable, I realized. I was hoping that there was some clue in the fact that the path makes a difference.

SVN client is Tortoise.

I have done a fresh checkout and the problem persists, so it isn't some weirdness with a tainted file in the source tree, I don't think.

--
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: Possible chmod problem with a path [WARNING: SPF validation failed]

[Andrey Repin]

Greetings, Phil Smith!

>>Please use Cygwin paths with Cygwin tools.
>>Windows paths are not guaranteed to work with every Cygwin tool.

> This is scripted, and while I can hack it to use Cygwin paths, it probably
> shouldn't be lying to me, saying that it worked. And it did work before,
> still does with older Cygwin (on another machine).

"It did work before" doesn't automatically mean "nothing has changed".
Please read the release notes for Cygwin 1.7.34 and the relevant article in
the documentation http://cygwin.com/cygwin-ug-net/ntsec.html

>>What you are doing may or may not work, depends, if you are using Cygwin or
>>native Subversion client.
>>In either case, it isn't very bright idea to enforce POSIX access mask outside
>>Cygwin tree, unless you know what you are doing and absolutely need it.
>From your description, you don't need it at all.

> I'm not actually trying to enforce POSIX anything--I'm trying to be able to
> read the build artifacts,

You are trying to solve your issue by bending Windows permission model into
POSIX access mask. Which by definition is prone to be sloppy and approximate
at best.

> which were put there via mv and cp.

Assuming you did it under the same user, I see no reason for it to not be
readable.
But since it is not, it automatically raises a red flag - SOMETHING IS
FUNDAMENTALLY WRONG.
I suspect you are trying to cure a symptom of a failed system design.

> The compiler is native Windows, isn't creating the artifacts with any special
> permissions.

So, remove any special permissions treatment in Cygwin - mount the dir with
"noacl" flag.

> So there's actually another mystery, which is why the artifacts
> don't have the right permissions in the first place.

They do have right permissions, I presume. But they are not POSIX permissions.
Do note the little "+" at the end of POSIX access mask - it is subtly hinting
that there's more to it, than what meets the eye.

> With the cobbled-together environment (CMake, the Dignus compiler, Cygwin)
> this may not be really diagnosable, I realized. I was hoping that there was
> some clue in the fact that the path makes a difference.

> SVN client is Tortoise.

So, I was right. Mixing native and Cygwin tools is only possible, when you
100% know what you are doing. And account for consequences in advance.

> I have done a fresh checkout and the problem persists, so it isn't some
> weirdness with a tainted file in the source tree, I don't think.

/etc/fstab:

none /cygdrive cygdrive noacl,binary,posix=0,user 0 0

This may help. Scrap the current checkout/build you;ve messed with and try
again after changing the mount options.
Make sure you've restarted all the Cygwin apps (rebooting the box isn't a bad
idea).


-- 
With best regards,
Andrey Repin
Monday, March 30, 2015 18:14:31

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: Possible chmod problem with a path [WARNING: SPF validation failed]

[Phil Smith]

Well well -- making that fstab change alone (and rebooting) seems to have fixed it! Release notes says:

Since 1.7.34, chmod does not always affect the POSIX permission mask as returned by stat(2) or printed by ls(1), due to the improved POSIX ACL handling. However, that's still far from perfect, so, as a temporary workaround, chmod now checks if secondary groups and users in the ACL have more permissions than the primary group. If so, the permissions of the secondary users and groups will be reduced according to the mask given by the new primary group permissions. I.e, chmod 600 will remove all permissions from the primary group as well as all secondary user and group entries in the ACL.

I read that as, "Here be dragons, and your mileage may vary". So I'll be wary of this, and tell the rest of the team about it, lest they hit similar problems (and spend a bunch of time banging heads on walls!)

For the record, if someone is reading this later:
- I don't believe SVN is involved, since it happens with C:\temp (and C:/temp) as well
- Cygwin seems to have been getting in the way of all file access, since even Windows utilities could not read the files

Thanks for the help!

...phsiii

-----Original Message-----
From: Andrey Repin [mailto:anrdaemon@yandex.ru] 
Sent: Monday, March 30, 2015 11:28 AM
To: Phil Smith; cygwin@cygwin.com
Subject: Re: Possible chmod problem with a path [WARNING: SPF validation failed]

Greetings, Phil Smith!

>>Please use Cygwin paths with Cygwin tools.
>>Windows paths are not guaranteed to work with every Cygwin tool.

> This is scripted, and while I can hack it to use Cygwin paths, it probably
> shouldn't be lying to me, saying that it worked. And it did work before,
> still does with older Cygwin (on another machine).

"It did work before" doesn't automatically mean "nothing has changed".
Please read the release notes for Cygwin 1.7.34 and the relevant article in
the documentation http://cygwin.com/cygwin-ug-net/ntsec.html

>>What you are doing may or may not work, depends, if you are using Cygwin or
>>native Subversion client.
>>In either case, it isn't very bright idea to enforce POSIX access mask outside
>>Cygwin tree, unless you know what you are doing and absolutely need it.
>From your description, you don't need it at all.

> I'm not actually trying to enforce POSIX anything--I'm trying to be able to
> read the build artifacts,

You are trying to solve your issue by bending Windows permission model into
POSIX access mask. Which by definition is prone to be sloppy and approximate
at best.

> which were put there via mv and cp.

Assuming you did it under the same user, I see no reason for it to not be
readable.
But since it is not, it automatically raises a red flag - SOMETHING IS
FUNDAMENTALLY WRONG.
I suspect you are trying to cure a symptom of a failed system design.

> The compiler is native Windows, isn't creating the artifacts with any special
> permissions.

So, remove any special permissions treatment in Cygwin - mount the dir with
"noacl" flag.

> So there's actually another mystery, which is why the artifacts
> don't have the right permissions in the first place.

They do have right permissions, I presume. But they are not POSIX permissions.
Do note the little "+" at the end of POSIX access mask - it is subtly hinting
that there's more to it, than what meets the eye.

> With the cobbled-together environment (CMake, the Dignus compiler, Cygwin)
> this may not be really diagnosable, I realized. I was hoping that there was
> some clue in the fact that the path makes a difference.

> SVN client is Tortoise.

So, I was right. Mixing native and Cygwin tools is only possible, when you
100% know what you are doing. And account for consequences in advance.

> I have done a fresh checkout and the problem persists, so it isn't some
> weirdness with a tainted file in the source tree, I don't think.

/etc/fstab:

none /cygdrive cygdrive noacl,binary,posix=0,user 0 0

This may help. Scrap the current checkout/build you;ve messed with and try
again after changing the mount options.
Make sure you've restarted all the Cygwin apps (rebooting the box isn't a bad
idea).


-- 
With best regards,
Andrey Repin
Monday, March 30, 2015 18:14:31

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