|

»

»

rsync problems from Vista installed cygwin, ok on XP

View: New views

10 Messages — Rating Filter: Alert me

	rsync problems from Vista installed cygwin, ok on XP by DaveB :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message My cygwin on Vista seems to work but when I try to do rsync to fixup files on my unix ftp server, it chokes with lots of errors and does a bizarre reset of the permission bits for the destination folder. Here's what happens: [this is the same rsync command that works fine on XP]: =========================== $ rsync -avz --stats --progress -e ssh . mylogin@myftp.com:/mypath/wherever/ mylogin@myftp.com's password: xxxxxx building file list ... 8 files to consider ./ rsync: failed to modify permissions on "/mypath/wherever/.": Permission denied (13) rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx": Permission denied (13) rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx": Permission denied (13) ...etc... rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission denied (13) * Skipping everything below this failed directory * ...etc...stats...then... rsync error: some files could not be transferred (code 23) at /home/lapo/packaging/tmp/rsync-2.6.6/main.c(791) ============================= Then after I have done this, I find that the remote directory has had all its permission bits turned off (chmod 0) and the files in the folder are not sync'd. As I said, this is a sequence I have used many times on XP and continues to work there. Any suggestions? PS After fixing the documented mkpasswd/Vista problem, cygwin starts without errors on Vista but then behaves as described above. Here is the output of a cygcheck -c (I have updated rsync to 2.6.6 as you can see)..... C:\cygwin>bin\cygcheck -c Cygwin Package Information Package Version Status _update-info-dir 00516-1 OK alternatives 1.3.29a-1 OK ash 20040127-3 OK base-files 3.7-1 OK base-passwd 2.2-1 OK bash 3.2.17-15 OK bzip2 1.0.3-2 OK catdoc 0.94.2-2 OK coreutils 6.9-2 OK crypt 1.1-1 OK cygrunsrv 1.17-1 OK cygutils 1.3.1-1 OK cygwin 1.5.24-2 OK cygwin-doc 1.4-4 OK diffutils 2.8.7-1 OK editrights 1.01-1 OK enscript 1.6.4-1 OK expat 1.95.8-2 OK findutils 4.3.4-1 OK fontconfig 2.4.1-5 OK freetype2 2.1.9-1 OK gawk 3.1.5-4 OK gdbm 1.8.3-8 OK gettext 0.15-1 OK grep 2.5.1a-2 OK groff 1.18.1-2 OK gzip 1.3.12-1 OK less 381-1 OK lftp 3.5.9-1 OK libbz2_1 1.0.3-2 OK libdb4.2 4.2.52-1 OK libdb4.3 4.3.28-1 OK libexpat0 1.95.8-2 OK libfontconfig1 2.4.1-5 OK libfreetype26 2.1.9-1 OK libgcrypt 1.2.1-1 OK libgdbm 1.8.0-5 OK libgdbm-devel 1.8.3-8 OK libgdbm3 1.8.3-3 OK libgdbm4 1.8.3-8 OK libgnutls11 1.0.25-2 OK libgpg-error 1.1-1 OK libiconv2 1.11-1 OK libintl 0.10.38-3 OK libintl1 0.10.40-1 OK libintl2 0.12.1-3 OK libintl3 0.14.5-1 OK libintl8 0.15-1 OK libncurses5 5.2-1 OK libncurses6 5.2-8 OK libncurses7 5.3-4 OK libncurses8 5.5-3 OK libopencdk8 0.5.7-1 OK libpcre0 6.6-1 OK libpopt0 1.6.4-4 OK libreadline4 4.1-2 OK libreadline5 4.3-5 OK libreadline6 5.2.4-8 OK libtasn1 0.2.15-1 OK libXft 2.1.6-1 OK libXft1 1.0.0-1 OK libXft2 2.1.6-1 OK login 1.9-7 OK man 1.6e-1 OK minires 1.01-1 OK mktemp 1.5-4 OK ncurses 5.5-3 OK openssh 4.6p1-1 OK openssl 0.9.8e-3 OK openssl097 0.9.7l-1 OK pcre 6.6-1 OK perl 5.8.7-5 OK ping 1.0-1 OK rebase 2.4.3-1 OK rsync 2.6.6-1 OK run 1.1.10-1 OK sed 4.1.5-2 OK suite3270 3.3.4p7-1 OK tar 1.16.1-1 OK tcltk 20060202-1 OK termcap 20050421-1 OK terminfo 5.5_20061104-1 OK texinfo 4.8a-1 OK which 1.7-1 OK whois 4.7.20-1 OK X-startup-scripts 1.0.11-1 OK xorg-x11-base 6.8.99.901-1 OK xorg-x11-bin 6.8.99.901-1 Incomplete xorg-x11-bin-dlls 6.8.99.901-1 OK xorg-x11-bin-lndir 6.8.99.901-1 OK xorg-x11-etc 6.8.99.901-1 OK xorg-x11-fenc 6.8.99.901-1 OK xorg-x11-fnts 6.8.99.901-1 OK xorg-x11-libs-data 6.8.99.901-1 OK xorg-x11-xwin 6.8.99.901-1 OK xterm 202-1 OK zlib 1.2.3-2 OK C:\cygwin>
	Re: rsync problems from Vista installed cygwin, ok on XP by fraeone :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Unfortunately I'm having exactly the same problem with rsyncing from a Vista machine to an OS X server. I thought it was because I was using the -a flag (which includes preserving permissions) but removing that argument didn't solve the problem. DaveB wrote: My cygwin on Vista seems to work but when I try to do rsync to fixup files on my unix ftp server, it chokes with lots of errors and does a bizarre reset of the permission bits for the destination folder. Here's what happens: [this is the same rsync command that works fine on XP]: =========================== $ rsync -avz --stats --progress -e ssh . mylogin@myftp.com:/mypath/wherever/ mylogin@myftp.com's password: xxxxxx building file list ... 8 files to consider ./ rsync: failed to modify permissions on "/mypath/wherever/.": Permission denied (13) rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx": Permission denied (13) rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx": Permission denied (13) ...etc... rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission denied (13) * Skipping everything below this failed directory * ...etc...stats...then... rsync error: some files could not be transferred (code 23) at /home/lapo/packaging/tmp/rsync-2.6.6/main.c(791) ============================= Then after I have done this, I find that the remote directory has had all its permission bits turned off (chmod 0) and the files in the folder are not sync'd. As I said, this is a sequence I have used many times on XP and continues to work there.
	Re: rsync problems from Vista installed cygwin, ok on XP by Corinna Vinschen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Aug 13 05:28, DaveB wrote: > > My cygwin on Vista seems to work but when I try to do rsync to fixup files on > my unix ftp server, it chokes with lots of errors and does a bizarre reset > of the permission bits for the destination folder. Here's what happens: > [this is the same rsync command that works fine on XP]: > > =========================== > $ rsync -avz --stats --progress -e ssh . mylogin@...:/mypath/wherever/ > mylogin@...'s password: xxxxxx > building file list ... > 8 files to consider > ./ > rsync: failed to modify permissions on "/mypath/wherever/.": Permission > denied (13) > rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx": > Permission denied (13) > rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx": > Permission denied (13) > ...etc... > rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission denied > (13) > * Skipping everything below this failed directory * http://cygwin.com/acronyms/#WJFFM For testing I copied over the whole /usr directory from my Vista box to a Linux machine. I'm rather puzzled how setting permissions on the remote machine should be affected by the OS of the source machine. I guess we need much more information. Are the affected directories Cygwin-created directories or natively created dirs? Do they contain spaces or native characters? What are the local permissions on them (getfacl/cacls)? Does your Vista account have admin privileges? UAC switched on? If so, is rsync running normally with reduced privileges or "as administrator"? Is your remote Unix account root or non-root? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
	Re: rsync problems from Vista installed cygwin, ok on XP by DaveB :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Corinna Vinschen-2 wrote: For testing I copied over the whole /usr directory from my Vista box to a Linux machine. I'm rather puzzled how setting permissions on the remote machine should be affected by the OS of the source machine. I guess we need much more information. Are the affected directories Cygwin-created directories or natively created dirs? Do they contain spaces or native characters? What are the local permissions on them (getfacl/cacls)? Does your Vista account have admin privileges? UAC switched on? If so, is rsync running normally with reduced privileges or "as administrator"? Is your remote Unix account root or non-root? Corinna OK, encouraged by hearing that it works for you from Vista to a Linux machine, I have retraced my steps and tried a much simpler contrived example. I set up a little folder tree c:\4up with a single file called somejunk.txt and one subfolder with two files, a txt and a jpg, latter with spaces but certainly no special characters. That's on the Vista pc. Then I putty'd across to my ftp area on a Linux server and created a new subfolder there called .../4up to copy these files to via rsync. ls shows total 0 in putty. Then back on Vista pc in cygwin I cd'd to the 4up folder and typed in this dry run rsync command.... $ rsync -avzn --stats --progress -e ssh . xxxx@myhost.net:/home/xxx/yyy/4up It happily responded, listing the 2 directories and 3 files and no errors. I then repeated the command without the dry run -n flag... ie set it live. It came up with all the errors as before... ========================================================== $ rsync -avz --stats --progress -e ssh . xxxx@myhost.net:/home/xxx/yyy/4up xxxx@myhost.net's password: building file list ... 5 files to consider ./ rsync: failed to modify permissions on "/home/xxx/yyy/4up/.": Permission denied (13) rsync: recv_generator: failed to stat "/home/xxx/yyy/4up/somejunk.txt": Permission denied (13) 20070709 mach refresh issue/ rsync: recv_generator: mkdir "/home/xxx/yyy/4up/20070709 mach refresh issue" failed: Permission denied (13) * Skipping everything below this failed directory * rsync: failed to modify permissions on "/home/xxx/yyy/4up/20070709 mach refresh issue": Permission denied (13) rsync: recv_generator: mkdir "/home/xxx/yyy/4up/." failed: Permission denied (13) * Skipping everything below this failed directory * etc... =========================== and after doing this failed rsync, I went back to the putty window to look at the remote machine and typed ls again... and bingo... permission denied. cd .. and ls -l shows the directory 4up with permission now set to 0: d--------- 2 xxxx xxxxx 48 Aug 17 07:42 4up/ =========================== Let me answer the rest of the questions if I can. The affected directories are not cygwin created, now or before. They are natively created. They do not contain special chars, nor does the full path to the first file even contain a space c:\4up\somjunk.txt but the subfolder and the two files in it contain spaces. Local permissions... haven't used getfacl before but tried it in cygwin and got this... ================================ daveb@daveb9400 /cygdrive/c/4up $ getfacl * # file: 20070709 mach refresh issue # owner: daveb # group: None user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask:rwx # file: somejunk.txt # owner: daveb # group: None user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask:rwx other:--- ========================= Vista account is only one on machine, has admin privileges. UAC is switched on. I did have cygwin, hence rsync running normally in this test, but now that you remind me, I also tried it before using "Run As Administrator" on cygwin. Made no difference. Remote unix account is non root... I am using a service provider's Linux box, don't know much about the machine, but I have 200GB of file space available up there somewhere in the US. I can putty to it and type in some commands to report info back if there is something specific to find out. Also can talk to their tech support 24/7.
	Re: rsync problems from Vista installed cygwin, ok on XP by Igor Peshansky :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, 17 Aug 2007, DaveB wrote: > Corinna Vinschen-2 wrote: > > > > For testing I copied over the whole /usr directory from my Vista box > > to a Linux machine. I'm rather puzzled how setting permissions on the > > remote machine should be affected by the OS of the source machine. > > > > I guess we need much more information. Are the affected directories > > Cygwin-created directories or natively created dirs? Do they contain > > spaces or native characters? What are the local permissions on them > > (getfacl/cacls)? Does your Vista account have admin privileges? UAC > > switched on? If so, is rsync running normally with reduced privileges > > or "as administrator"? Is your remote Unix account root or non-root? > > > > Corinna > > OK, encouraged by hearing that it works for you from Vista to a Linux > machine, I have retraced my steps and tried a much simpler contrived > example. I set up a little folder tree c:\4up with a single file called > somejunk.txt and one subfolder with two files, a txt and a jpg, latter > with spaces but certainly no special characters. That's on the Vista > pc. Then I putty'd across to my ftp area on a Linux server and created > a new subfolder there called .../4up to copy these files to via rsync. > ls shows total 0 in putty. > Then back on Vista pc in cygwin I cd'd to the 4up folder and typed in > this dry run rsync command.... > > $ rsync -avzn --stats --progress -e ssh . xxxx@...:/home/xxx/yyy/4up > > It happily responded, listing the 2 directories and 3 files and no > errors. I then repeated the command without the dry run -n flag... ie > set it live. It came up with all the errors as before... > > ========================================================== > $ rsync -avz --stats --progress -e ssh . xxxx@...:/home/xxx/yyy/4up > > xxxx@...'s password: > building file list ... > 5 files to consider > ./ > rsync: failed to modify permissions on "/home/xxx/yyy/4up/.": Permission > denied (13) > rsync: recv_generator: failed to stat "/home/xxx/yyy/4up/somejunk.txt": > Permission denied (13) > 20070709 mach refresh issue/ > rsync: recv_generator: mkdir "/home/xxx/yyy/4up/20070709 mach refresh issue" > failed: Permission denied (13) > * Skipping everything below this failed directory * > rsync: failed to modify permissions on "/home/xxx/yyy/4up/20070709 mach > refresh issue": Permission denied (13) > rsync: recv_generator: mkdir "/home/xxx/yyy/4up/." failed: Permission denied > (13) > * Skipping everything below this failed directory * > > etc... > =========================== > > and after doing this failed rsync, I went back to the putty window to > look at the remote machine and typed ls again... and bingo... permission > denied. cd .. and ls -l shows the directory 4up with permission now set > to 0: > d--------- 2 xxxx xxxxx 48 Aug 17 07:42 4up/ > > =========================== > > Let me answer the rest of the questions if I can. > The affected directories are not cygwin created, now or before. They > are natively created. > They do not contain special chars, nor does the full path to the first > file even contain a space c:\4up\somjunk.txt but the subfolder and the > two files in it contain spaces. > Local permissions... haven't used getfacl before but tried it in cygwin > and got this... > > ================================ > daveb@daveb9400 /cygdrive/c/4up > $ getfacl * > # file: 20070709 mach refresh issue > # owner: daveb > # group: None > user::--- > group::--- > group:SYSTEM:rwx > group:Administrators:rwx > group:Users:r-x > mask:rwx > other:--- > default:group:SYSTEM:rwx > default:group:Administrators:rwx > default:group:Users:r-x > default:mask:rwx > > # file: somejunk.txt > # owner: daveb > # group: None > user::--- > group::--- > group:SYSTEM:rwx > group:Administrators:rwx > group:Users:r-x > mask:rwx > other:--- > > ========================= > > Vista account is only one on machine, has admin privileges. > UAC is switched on. > I did have cygwin, hence rsync running normally in this test, but now that > you remind me, I also tried it before using "Run As Administrator" on > cygwin. Made no difference. > Remote unix account is non root... I am using a service provider's Linux > box, don't know much about the machine, but I have 200GB of file space > available up there somewhere in the US. > I can putty to it and type in some commands to report info back if there > is something specific to find out. Also can talk to their tech support > 24/7. Ok, here's a WAG. Your problem stems from the fact that the Unix permissions on that directory really are 0. All of the access information is stored in separate ACLs, which rsync does not copy. Thus, it sets the permissions on the remote copy to 0, and, obviously, is unable to write to that directory afterwards. You can run "chmod -R 775" on that directory, which should, if my WAG above is correct, fix your rsync problem. Igor P.S. Before you ask, I'm not aware of any way to make rsync copy the ACLs. -- http://cs.nyu.edu/~pechtcha/ \|\ _,,,---,,_ pechtcha@... \| igor@... ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) \|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
	Re: rsync problems from Vista installed cygwin, ok on XP by DaveB :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Igor Peshansky wrote: > DaveB wrote....[snip] > Local permissions... haven't used getfacl before but tried it in cygwin > and got this... > > ================================ > daveb@daveb9400 /cygdrive/c/4up > $ getfacl * > # file: 20070709 mach refresh issue > # owner: daveb > # group: None > user::--- > group::--- > group:SYSTEM:rwx > group:Administrators:rwx > group:Users:r-x > mask:rwx > other:--- > default:group:SYSTEM:rwx > default:group:Administrators:rwx > default:group:Users:r-x > default:mask:rwx > > # file: somejunk.txt > # owner: daveb > # group: None > user::--- > group::--- > group:SYSTEM:rwx > group:Administrators:rwx > group:Users:r-x > mask:rwx > other:--- > > ========================= > > Vista account is only one on machine, has admin privileges. > UAC is switched on. > I did have cygwin, hence rsync running normally in this test, but now that > you remind me, I also tried it before using "Run As Administrator" on > cygwin. Made no difference. > ...[snip] Ok, here's a WAG. Your problem stems from the fact that the Unix permissions on that directory really are 0. All of the access information is stored in separate ACLs, which rsync does not copy. Thus, it sets the permissions on the remote copy to 0, and, obviously, is unable to write to that directory afterwards. You can run "chmod -R 775" on that directory, which should, if my WAG above is correct, fix your rsync problem. Igor P.S. Before you ask, I'm not aware of any way to make rsync copy the ACLs. Hey that did it!!! Thanks!!! In cygwin I did an ls -laR and confirmed the directory had d------ privileges. The first attempt to chmod -R 775 failed, then I restarted cygwin with "Run As Administrator" and it worked. The first attempt to rsync then failed because the folder up there on the Linux machine was still set to d------ from the last attempt... so I went in and chmod'd that to 755 (not 775, deliberately different)... then tried the rsync again... hummed along no problems, then after completion I went back to the Linux machine and the test files were all there and the privileges for the folder had been changed from 755 to 775 (drwxrwxr-x)... perfect. So... two interesting followon points... 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in the first place when I created this little test area in Vista? After all, I could do directory listings even in cygwin, so it seems a bit of an unfair trick on me that the access was actually set to 000... In fact, thinking about it, I guess it inherited the 000 from the parent c:\ directory. But just seems a bit odd to me that I ended up with this 000 setting which in unix systems means one cannot even do an ls yet I was totally unaware of it and able to see all the files 2. Given the above, and Igor's comments that rsync will not copy ACLs, why in the world did rsync copy the strange 000 flags... hmmm... not sure about this, in a way it is 100% correct to do that, but maybe there should be (maybe there already is??) a flag on rsync which stops it setting permissions during the transfers. Having made these observations, I must say that in my case the problem is now 100% solved by Igor's suggestion... I will simply do that chmod 775 -R to all my file trees I intend to sync in future. But this sure is a trap for the innocent... thanks again Igor
	Re: rsync problems from Vista installed cygwin, ok on XP by Corinna Vinschen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Aug 18 21:06, DaveB wrote: > So... two interesting followon points... > > 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in > the first place when I created this little test area in Vista? After all, I The directory has been created using native Windows tools. The permissions given using native Windows tools are strange and don't follow POSIX rules. It's perfectly valid that you can access a directory under Windows but get 000 POSIX permissions. You did see the '+' at the end of the permission in ls -l? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
	Re: rsync problems from Vista installed cygwin, ok on XP by DaveB :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Corinna Vinschen-2 wrote: On Aug 18 21:06, DaveB wrote: > So... two interesting followon points... > > 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in > the first place when I created this little test area in Vista? After all, I The directory has been created using native Windows tools. The permissions given using native Windows tools are strange and don't follow POSIX rules. It's perfectly valid that you can access a directory under Windows but get 000 POSIX permissions. You did see the '+' at the end of the permission in ls -l? OK, I now see this + and had no idea what it meant... but have now found the doc in cygwin by typing "info ls", where it says... Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. For a file with an extended access control list, a `+' character is listed. Basic access control lists are equivalent to the permissions listed, and are not considered an alternate access method. Interesting. So if it knows there is an ACL which overrides the ------ permissions that were inherited from C:\ then why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files... even if it cannot directly read the ACL maybe it could allow you to invoke some special rsync permissions sync'ing flag? I looked in the man rsync doc, and found some flags that might be helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite let you do automatically what would make sense, which is to create rsync'd files with rwx for the exe's and rw for the others. Not sure what the best way out of here is...??? I'm beginning to understand this a bit better, but it sure is a minefield... will generate ongoing problems for innocent future users. PS Can anyone point to a good article on ACL that explains the relationship to these ls -l permissions also?
	Re: rsync problems from Vista installed cygwin, ok on XP by Igor Peshansky :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Mon, 20 Aug 2007, DaveB wrote: > Corinna Vinschen-2 wrote: > > > > On Aug 18 21:06, DaveB wrote: > >> So... two interesting followon points... > >> > >> 1. Why didn't the ACLs get set to something reasonable as opposed to > >> 000 in the first place when I created this little test area in Vista? > >> After all, I > > > > The directory has been created using native Windows tools. The > > permissions given using native Windows tools are strange and don't > > follow POSIX rules. It's perfectly valid that you can access a > > directory under Windows but get 000 POSIX permissions. You did see > > the '+' at the end of the permission in ls -l? > > OK, I now see this + and had no idea what it meant... but have now found > the doc in cygwin by typing "info ls", where it says... > > Following the file mode bits is a single character that specifies > whether an alternate access method such as an access control list > applies to the file. When the character following the file mode > bits is a space, there is no alternate access method. When it is > a printing character, then there is such a method. > > For a file with an extended access control list, a `+' character is > listed. Basic access control lists are equivalent to the > permissions listed, and are not considered an alternate access > method. > > Interesting. So if it knows there is an ACL which overrides the ------ > permissions that were inherited from C:\ then why can't the cygwin port > of rsync allow a Windows-friendly option for rsync'ing these files... > even if it cannot directly read the ACL maybe it could allow you to > invoke some special rsync permissions sync'ing flag? > > I looked in the man rsync doc, and found some flags that might be > helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite > let you do automatically what would make sense, which is to create > rsync'd files with rwx for the exe's and rw for the others. > > Not sure what the best way out of here is...??? I'm beginning to > understand this a bit better, but it sure is a minefield... will > generate ongoing problems for innocent future users. You misunderstand your problem. The problem is not that rsync on the source side cannot read the files (it can, since the ACLs allow it to). The problem is that the rsync on the destination side copies only the Unix permission bits from the source side (which are 000), and then it is unable to write to that directory (because the permissions are 000). What you want is some way of getting rsync to not copy permissions, or making rsync ACL-aware. I don't know of any way to do either, but then, I haven't used rsync extensively. Perhaps the documentation holds the answer. > PS Can anyone point to a good article on ACL that explains the > relationship to these ls -l permissions also? I'm sure MSDN has a lot of info on ACLs in general and on their use in Windows. If you want to know specifically how Cygwin maps ACLs to Unix permission bits, see <http://cygwin.com/cygwin-ug-net/ntsec.html>. Igor -- http://cs.nyu.edu/~pechtcha/ \|\ _,,,---,,_ pechtcha@... \| igor@... ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) \|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
	Re: rsync problems from Vista installed cygwin, ok on XP by DaveB :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Igor Peshansky wrote: On Mon, 20 Aug 2007, DaveB wrote: > Corinna Vinschen-2 wrote: > > > > On Aug 18 21:06, DaveB wrote: > >> So... two interesting followon points... > >> > >> 1. Why didn't the ACLs get set to something reasonable as opposed to > >> 000 in the first place when I created this little test area in Vista? > >> After all, I > > > > The directory has been created using native Windows tools. The > > permissions given using native Windows tools are strange and don't > > follow POSIX rules. It's perfectly valid that you can access a > > directory under Windows but get 000 POSIX permissions. You did see > > the '+' at the end of the permission in ls -l? > > OK, I now see this + and had no idea what it meant... but have now found > the doc in cygwin by typing "info ls", where it says... > > Following the file mode bits is a single character that specifies > whether an alternate access method such as an access control list > applies to the file. When the character following the file mode > bits is a space, there is no alternate access method. When it is > a printing character, then there is such a method. > > For a file with an extended access control list, a `+' character is > listed. Basic access control lists are equivalent to the > permissions listed, and are not considered an alternate access > method. > > Interesting. So if it knows there is an ACL which overrides the ------ > permissions that were inherited from C:\ then why can't the cygwin port > of rsync allow a Windows-friendly option for rsync'ing these files... > even if it cannot directly read the ACL maybe it could allow you to > invoke some special rsync permissions sync'ing flag? > > I looked in the man rsync doc, and found some flags that might be > helpful ... namely -p -E and --chmod. But even chmod=XXX doesn't quite > let you do automatically what would make sense, which is to create > rsync'd files with rwx for the exe's and rw for the others. > > Not sure what the best way out of here is...??? I'm beginning to > understand this a bit better, but it sure is a minefield... will > generate ongoing problems for innocent future users. You misunderstand your problem. The problem is not that rsync on the source side cannot read the files (it can, since the ACLs allow it to). The problem is that the rsync on the destination side copies only the Unix permission bits from the source side (which are 000), and then it is unable to write to that directory (because the permissions are 000). What you want is some way of getting rsync to not copy permissions, or making rsync ACL-aware. I don't know of any way to do either, but then, I haven't used rsync extensively. Perhaps the documentation holds the answer. > PS Can anyone point to a good article on ACL that explains the > relationship to these ls -l permissions also? I'm sure MSDN has a lot of info on ACLs in general and on their use in Windows. If you want to know specifically how Cygwin maps ACLs to Unix permission bits, see <http://cygwin.com/cygwin-ug-net/ntsec.html>. Igor Don't think I misunderstood... what I was saying above agrees with you - the ACLs allow cygwin/rsync to read the files, but it then proceeds to transfer the posix permissions, which are 000. The ntsec article above is very helpful actually, explaining the problem more clearly - there is a mismatch between posix and NT security. cygwin is an environment trying to bridge the gap. It seems that a good solution might be to provide a cygwin environment variable which "OR"s the read/write access of the current user with the posix flags right from the start... Then even an ls -l would come up with rwx where applicable (instead of --- at the moment), and programs like cygwin/rsync would then behave themselves and cause less of a surprise to the end user. My earlier comment said >why can't the cygwin port of rsync allow a Windows-friendly option for rsync'ing these files If there was a Windows friendly env variable that made current ACL the default reported security setting for the rwx flag (at least for the owner) then there would be no need to fiddle with anything in rsync, fix the problem upstream. Cygwin does things like this in other areas - eg it provides env variables for dealing better with the case dependence in filenames which is fundamentally different between unix and Windows. So why not make it behave more like Windows in the security area? Until it was pointed out to me what was going on here, I was oblivious to the --- posix setting and happily reading and writing files in this directory in Windows, so of course it was a surprise when rsync's copy of the directory to a unix system zapped the rwx setting of the directory copy up there. As Igor is saying, this is the underlying problem... >The problem is not that rsync on the >source side cannot read the files (it can, since the ACLs allow it to). >The problem is that the rsync on the destination side copies only the Unix >permission bits from the source side (which are 000), and then it is >unable to write to that directory (because the permissions are 000). I agree with this but think that rsync is not the problem here... the real problem is the underlying behaviour of cygwin, which as we observe can read the source files just fine, but tells rsync (and ls -l and everyone else) that it cannot (000). An environment variable to change this behaviour and make some use of the ACLs when reporting the permission bits to rsync, ls -l and anyone else who asks, would IMHO solve the problem more elegantly than attacking each problem area (like rsync) individually. In fact, rsync does have flags which come close to letting one deal with this problem (--chmod= discussed above) but I don't think this is the place to fix the problem. Cygwin is a great attempt to provide a unix like environment on Windows and is saddled with the responsibility of dealing with these fundamental incompatibilities - in the case of file name case dependence, it does such a good job that I hadn't noticed there was a problem really... of course there is and there is no perfect solution. Similarly, any attempt to use ACLs has inherent problems too - the solution cannot be perfect, because ACLs do not map 1-1 to the posix permission structure. But the objective should be to make the behaviour roughly like Windows at least... and at the moment it is dramatically different. (ie can read a file in Windows even though permissions are reported as ---). Having said all that, I must hasten to add - as I did earlier - that in my case the problem is now totally resolved... I will be doing chmod -R's and everything will work for me. The discussion above is a suggestion for making the cygwin environment "more Windows-compatible" and therefore causing less surprises for users in general. Cygwin/rsync is a great environment and has solved a huge problem for me when dealing with backups and ftp sites. Can't praise it enough. This permission stuff is a tricky and near intractable problem, I just think that there is a way of improving the behaviour here.