DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=tQShipWlGol686/DymsRkx2Axhwol
	QKJrxNMrzU9cEng2a7A2goaKOmVJowwj7N2acZYxO8lJU1JzXUn0pEmfTHjORbvB
	wpE2V5CwfNml/VhMCSdIkJxqFOgpXFY7uAtprMSFRKp7p0eM06h1eIOq36IsAEOh
	ANsGUGd3Lkx4MA=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: Phil Smith <phil AT voltage DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Mon, 30 Mar 2015 10:14:34 -0700
Subject: RE: Possible chmod problem with a path [WARNING: SPF validation failed]
Message-ID: <84BCCD71182F0046BCD2FB054FE52379197703FE3E@HQMAILSVR02.voltage.com>
References: <84BCCD71182F0046BCD2FB054FE52379197703FDDD AT HQMAILSVR02 DOT voltage DOT com>   <131547857 DOT 20150330172345 AT yandex DOT ru>  <84BCCD71182F0046BCD2FB054FE52379197703FDF7 AT HQMAILSVR02 DOT voltage DOT com> <875705351 DOT 20150330182806 AT yandex DOT ru>
In-Reply-To: <875705351.20150330182806@yandex.ru>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

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 AT yandex DOT ru] 
Sent: Monday, March 30, 2015 11:28 AM
To: Phil Smith; cygwin AT cygwin DOT 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