rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Permission denied errors on files that?original


From: Peter Schuller
Subject: Re: [rdiff-backup-users] Permission denied errors on files that?originally have no user
Date: Wed, 5 Mar 2008 23:37:06 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

>   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 <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

Attachment: pgpsUSaY7NQ39.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]