This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: cp creates unreadable file on Windows 7


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]