Handful of files are giving me error 13, directory executable bit issue

[Matt McCutchen]

On Sun, 2008-07-06 at 17:54 -0700, mike wrote:
> On 7/6/08, Matt McCutchen <matt at mattmccutchen.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20080706/7182d079/attachment.bin