Re: [rdiff-backup-users] Re: Permission denied on file in backup repository

[Oliver Hookins]

On Wed Jun 11, 2008 at 23:45:31 -0400, Andrew Ferguson wrote:
> On Jun 11, 2008, at 11:12 PM, Oliver Hookins wrote:
>
>> On Wed Jun 11, 2008 at 23:05:15 -0400, Andrew Ferguson wrote:
>>>
>>> On Jun 11, 2008, at 10:10 PM, Oliver Hookins wrote:
>>>> Maybe I've confused you a little. Here is the file on the source:
>>>>
>>>> address@hidden ~]# ls -la /usr/bin/sudoedit
>>>> ---s--x--x 2 root root 164536 Mar  6 22:23 /usr/bin/sudoedit
>>>>
>>>> Here is the file on the destination:
>>>> address@hidden ~]$ ls -la server/usr/bin/sudoedit
>>>> ---s--x--x 1 backup backup 164536 Mar  6 22:23 server/usr/bin/ 
>>>> sudoedit
>>>>
>>>> Because this is a standard user, it can't even read the file that it
>>>> backed
>>>> up earlier. If we only stored the unix permissions in meta-data this
>>>> wouldn't be a problem.
>>>
>>> Ok, I just checked with the CVS version. That situation does not  
>>> cause a
>>> problem for rdiff-backup anymore.
>>
>> Great, I'll try it out. What is the new behaviour that prevents the
>> situation from being a problem?
>
> Since rdiff-backup is the owner of the unreadable file, it simply gives 
> itself read permission on the file for whichever operation it is  
> necessary, then re-adjusts the file after it is finished. This way, the 
> old behavior is preserved, but the bug is fixed.
>
> Why is the old behavior a good thing? ("---s--x--x 1 backup backup" on  
> destination) Because rdiff-backup uses the file's actual metadata in the 
> event that the metadata entry is missing or corrupt, and it also keeps 
> the whole process more rsync-like.

That makes a lot of sense and seems like the smart way to do things. Thanks
for your explanation!

-- 
Regards,
Oliver Hookins
Anchor Systems