X-Recipient: archive-cygwin AT delorie DOT com
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:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=eOAekUsCyBBTpySKZ3HmQEhfPe2WM
	YRa0jdwQRm0p2bCqWlxXvsnJJEzOMYuQBErdvaVUz/p/Dd2C/ZFNcmzQtuv++RiQ
	OzdPlXqTIEqOgP5qF4hb3KNmOiSWHEoS0J+E9PfrgtLjuAiKpvbVGqEny3T0I8D9
	MQfczTVFEKhv+0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=QsEDMpcv3SiTqCBqmmqcIjKUIB8=; b=hYS
	StUh+JU1zQP5DOHV8UgUAhOkIPN5zxtokwOHsiSHGh5MxD5sFuDKu5ChE/zvkWIN
	YF/pIU/LEtP+vrRt7GUE88ls4vHbxywJvrdahINvWoNQw+TqfCkCqW5kGjWRgjWs
	MAfiinyZMOgNydUoJLtMTHLhDu93PxTFPisEe8BM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mga02.intel.com
X-ExtLoop1: 1
From: "Frank, Matthew I" <matthew DOT i DOT frank AT intel DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: cp creates unreadable file on Windows 7
Date: Thu, 10 Oct 2013 22:13:23 +0000
Message-ID: <8FEF00DDD6C58843BF4ED3C1DCF80E9F6421A732@FMSMSX106.amr.corp.intel.com>
References: <8FEF00DDD6C58843BF4ED3C1DCF80E9F6421A227 AT FMSMSX106 DOT amr DOT corp DOT intel DOT com> <1616237262 DOT 20131010065014 AT mtu-net DOT ru>
In-Reply-To: <1616237262.20131010065014@mtu-net.ru>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r9AMDfvF015073

On 2013-10-09 18:27, Larry Hall (Cygwin) wrote:
>On 10/9/2013 5:30 PM, Frank, Matthew I wrote:
>> I believe my problem is identical to the one reported in:
>> http://cygwin.com/ml/cygwin/2012-02/msg00456.html, but that message chain ended with
>> "mount your file system noacl" which isn't an option for me, so I'm looking for
>> other alternatives.
>>
>> I create a file using cmd.exe in a directory created by cmd.exe.  Then in Cygwin bash I
>> mkdir a directory (two levels deep) and cp the file into the new directory.  The resulting
>> file is not readable by any Windows or Cygwin executable.  I can't say whether this is
>> correct or not, but it surprised me.
>>
>'bar' isn't owned by mifrank, Domain Users, or Everyone in its initial 
>location so the POSIX permissions for it don't include read access for
>any of the POSIX attributes (-rwxrwxrwx).  Try adding read permissions
>for mifrank to the file and/or directories and see if that helps.

'bar' is owned by amr\mifrank, but you are correct that 'bar' doesn't have
"amr\mifrank", "amr\domain users" or "Everyone" Access Control Entries.
      icacls /grant <ACE>:R dos-level1\bar
Where <ACE> is one of those three makes it so that cp produces a readable file.

But lots of things make cp produce a readable file.  For example if you repeat the
experiment starting under c:\users\<myuserid>\Documents\ instead of c:\, cp will
also produce a readable file.  Likewise if you cp into cyg-level1 instead of
cyg-level1/cyg-level2/.

It turns out that "cp --preserve=mode" does something closer to what I was expecting.
Roughly I was expecting cp to create the target file with the same ACL as
the source file, minus the umask, which is closer to the spirit of the semantics on
a non-acl filesystem ("copy the mode bits minus the umask from the source to the target"),
rather than "infer mode bits from the ACL in a very literal way and then construct an ACL
that implements the inferred mode bits."

cp --preserve=mode seems to copy the source's ACL and then also adds in the ACL produced
by inferring the mode bits.  Good enough (since the inferred mode bits are harmless.)

I'm sure that getting this right is much more complicated than it appears at first glance.
For example, while researching this reply I found:
http://michael.orlitzky.com/articles/problems_with_posix_acls_and_common_utilities.php
(And Orlitzky's blog post is about problems interacting with posix acls, which are
at least designed to be somewhat compatible with traditional unix mode bits.  Presumably
the translation from Windows ACLs is even harder.)

-Matt



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