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
