Re: [Duplicity-talk] Restore numeric owner?

[Dylan Martin]

Patch version 2!  This one actually does something!  (I think...)

Also attached is the crappy test script I wrote to verify that this
actually does something.  I don't really recommend anyone run this
script, but it might illustrate what I'm talking about.

Running "./test.sh 1" creates some dirs, files, users and chowns them
in suitable ways
Running "./test.sh 2" make a duplicity backup with all users present
on the system, removes the users, then creates a new user with a
different uid from before the backup was made and finally restores the
files.
There are two versions of the restore command in this shell script,
one using --numeric-owner and one not.  Comment out and try each to
see the difference.

On Wed, Oct 29, 2008 at 5:02 PM, Kenneth Loafman <address@hidden> wrote:
> Thank you for tackling this.  All patches appreciated!
>
> Dylan Martin wrote:
>> And I just found a bug in my patch:  some files which belong to a user
>> who's uname exists on the system running duplicity and the restored
>> system but where the uid is different will have their uid set to the
>> wrong number.  I'll try and come up with another patch tomorrow.
>>
>> On Wed, Oct 29, 2008 at 1:42 PM, Dylan Martin <address@hidden> wrote:
>>> And believe it or not, here's a patch which may or may not pass muster:
>>>
>>> On Wed, Oct 29, 2008 at 9:30 AM, Dylan Martin <address@hidden> wrote:
>>>> Okay, I'm going to take a peek at the code and if it's not over my
>>>> head, I'll send a patch.  Otherwise I'll make that request.
>>>>
>>>> On Tue, Oct 28, 2008 at 6:00 PM, Kenneth Loafman <address@hidden> wrote:
>>>>> Dylan Martin wrote:
>>>>>> When restoring a tar backup, you can specify --numeric-owner (at least
>>>>>> with GNU tar) and files will keep the numeric uid/gid from the
>>>>>> archive, even if they map to the different user names on the running
>>>>>> system.  This is useful if you're doing the restore on a different
>>>>>> system than the files will actually be used on.
>>>>>>
>>>>>> I'll explain my question another way in case I'm not making sense:
>>>>>> When I restore a system, I normally boot up with a CD or other media.
>>>>>> I then mount the hard drive of the victim machine and restore files
>>>>>> onto that hard drive.  If the /etc/passwd file on the CD is not the
>>>>>> same as the /etc/passwd file on the system I'm restoring, files will
>>>>>> belong to the wrong user when I finally reboot the system on it's own.
>>>>>>  Using tar, I can get around this with the --numeric-owner switch.
>>>>>>
>>>>>> Is there a way to do this with duplicity?  If not, It's a feature I'd
>>>>>> love to see.  Is there a best way to handle this situation?  Right
>>>>>> now, I think I'll have to restore to a directory, chroot, and then do
>>>>>> a complete restore again to reset all the uids and gids.
>>>>> I understand what you want to do, but at the moment duplicity does not
>>>>> support that.  It would be a good idea to submit a support request on
>>>>> the web for the new feature.
>>>>>
>>>>> ...Ken
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Duplicity-talk mailing list
>>>>> address@hidden
>>>>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>>>
>>>>>
>>
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>

duplicity-numeric-owner.patch
Description: Binary data

test.sh
Description: Bourne shell script