On Sun, 2008-07-06 at 17:54 -0700, mike wrote: > On 7/6/08, Matt McCutchen <[EMAIL PROTECTED]> wrote: > Actually, what happened was it created the local directory, without > the +x bit set. But I was running it as the owner, which should mean I > can still read/write/etc. to it.
No, that's not how Linux permissions work. Ownership of a file confers only the ability to change its permissions. The owner still needs execute permission on a directory to access files inside. > It seems like whatever system call or > sanity check rsync runs might not work correctly, because I could > manipulate and create files without an issue, but when running rsync > it failed on all the files underneath the non-x'ed directory. Could you manipulate files *inside* a nonexecutable destination directory? That's what rsync was trying to do. > To fix I removed them on the destination (local) side, chmod +x'ed all > the dirs on the server side, and re-ran it. Now I get no errors at > least, but who knows what mistakes the programmers will make in the > future that I am backing up... > > I am trying to determine if "-p" or "--perms" is the right switch > instead -E (I guess I do want to retain permissions after all) but I > want to -fix- the broken ones. Would that --chmod line above resolve > that? --chmod affects what rsync considers to be the source permissions. Thus, without -p it will only affect creation of new destination directories (though that is sufficient if you fix the existing directories and then use --chmod consistently), while with -p it will also fix existing directories. See the man page for more details. Matt
signature.asc
Description: This is a digitally signed message part
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
