Have found my solution ... robocopy. Using it's /secfix option copied files are owned by the copying user.
eg: robocopy x:\tmp .\tmp /e /secfix Note: you need a not-too-old version of Robocopy for the /secfix support (I was using v 1.96). On 16 March 2011 19:09, Peter Binney <peter.bin...@gmail.com> wrote: > Eric Blake <eblake <at> redhat.com> writes: > >> >> On 03/04/2011 11:12 AM, Peter Binney wrote: >> > When running "ls -l" the permissions field shows as "----------+". >> >> Which means that the owner has no permissions, but that there are ACLs >> which allow others permissions. Not entirely unusual, given Windows' >> ability to create files with a different owner than the current user, >> while allowing the current user to access the file (typically when done >> to places like the desktop, and caused by inheritance ACLs present on >> the directory where the problematic file is being created in the first >> place). >> >> > Oddly, "ls -l" shows the correct permissions if the pathname uses the >> > windows drive letter syntax. eg: >> > >> > $ pwd >> > /cygdrive/c >> > $ ls -l tmp/plb.txt >> > ----------+ 1 ga2binn Domain Users 5527 Mar 3 13:54 tmp/plb.txt >> > $ ls -l c:/tmp/plb.txt >> > -rw-r--r-- 1 ga2binn Domain Users 5527 Mar 3 13:54 c:/tmp/plb.txt >> >> That's because using a dos-style path disregards ACL parsing, and fakes >> the permission bits instead. The + shows that ACLs are present, and >> 'getfacl tmp/plb.txt' will show you the difference between the owner and >> your permissions. >> >> > Similarly, TAR images have no permissions on the files contained. eg: >> > >> > $ pwd >> > /cygdrive/c/tmp >> > $ tar cf - plb.txt | tar vtf - >> > ---------- ga2binn/Domain Users 5527 2011-03-03 13:54 plb.txt >> >> Here, the problem is that tar doesn't preserve ACLs by default, so the >> original POSIX mode (000) is preserved while the ACLs are lost, >> resulting in an truly inaccessible file (note that there is no longer a >> + in the listing). >> >> > >> > Even more oddly, this behaviour (both LS and TAR) occurs on a new PC >> > that I am moving to. >> >> That's another big case where the user ids on the old pc do not >> correpsond to the user ids on the new pc; copying preserved the old user >> id, but gave ACL access to the new user, resulting in odd permissions. >> > > Many thanks indeed for that info, Eric. > > I know it's not a Cygwin issue, but can you suggest an easy way to get > miserable Windows to copy files to a new machine in a way that does > give the current user ownership (ideally using some normal-ish Windows > commands)? > > I tried using Windows Explorer copies and Winzip-ed .zip archives - > both end up with the problem below. > > I have done this before when transferring PC's, but then I would have > been the same user on both, Here I am also moving to a different > domain\username on the new PC. > > -- > Peter > > > > > -- > 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 > > -- 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