permissions bug w/ --backup-dir or --backup option?

Carey Jung carey at
Fri Sep 21 00:13:26 EST 2001

> This works great for us, because 1) it's faster, and 2) we really don't
> care about the directory permissions/owners unless the directory is
> changed directly by a move/rename/delete.  That said, you do have a
> point.  (And, just because I don't use it, doesn't mean it's not right
> :^)

Here's the point:  If I need to restore an entire directory, I normally just
run rsync in reverse to blast it out.  No problem.  If, however, I need to
restore that directory from a backup-dir, i.e., a previous backup, the
permissions/ownership get lost, so I have to logon to the server and fix
them up myself.

Also, even if I'm just restoring a single file, when it gets pushed out, the
rsync daemon on the receiving end will touch the directory path to that file
and muck up permissions and ownership along the way, so again I have to
logon and clean it up.

Finally, yet another reason for doing this is to maintain the same behavior
for rsync, regardless of whether the backup-dir is on the same filesystem or
not.  This is not currently the case.

> Add one line to backup.c to do your thing.  There will be a little
> overhead, but it will work they way you want it to work, and smack
> permissions on all directories on the backup-dir path leading to the
> changed file(s).

Thanks!  I'll give it a try.


More information about the rsync mailing list