>   File "/usr/local/lib/python2.5/site-packages/rdiff_backup/Rdiff.py", line 
> 68, in write_delta
>     deltafile = librsync.DeltaFile(get_signature(basis), new.open("rb"))
>   File "/usr/local/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 
> 1057, in open
>     else: return open(self.path, mode)

And looking at the source here it's pretty clear that it simply opens
the file without special actions before hand, in order to generate the
delta.

I do not have a good grasp of the overall structure of
rdiff-backup. Is the bug that the file was written with such a mode to
begin with, or is the bug that it does not temporarily chmod the file
during the reading process? What is the intended/preferred behavior in
cases like this?

Would an acceptable solution be to never preserve an "u-r" mode for a
file (and "u-x" for directories) in the actual target, relying on the
separately tracked meta data for that? That would preserve the ability
to e.g. rsync -aVWP the files without special actions.

On the one hand the backup is supposed to match the thing being backed
up maximally, but on the other hand you want a backup to be as
*available* as possible. Things like not being able to read the backup
without first manually doing chmodding tricks, take away from that. I
have had similar cases before when an "rm -rf" on the target directory
was not possible unless done as root, due to "excessive", if you call
it that, preservations of modes by rdiff-backup when the
files/directories were written (I don't remember the exact
circumstances right now).

I'd be happy to look into fixing this myself, but it would be good to
hear opinions on the desired/intended behavior from someone in the
know, first.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org

Attachment: pgpiTgsgNmedT.pgp
Description: PGP signature

_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Reply via email to