[Top][All Lists]

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

Re: [Duplicity-talk] duplicity overwrites on restores .. Re: Duplicity w

From: edgar . soldin
Subject: Re: [Duplicity-talk] duplicity overwrites on restores .. Re: Duplicity wiped out my server
Date: Mon, 08 Jun 2015 18:20:48 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 08.06.2015 18:07, T. Prost wrote:
> Am Mittwoch, den 06.05.2015, 14:34 +0200 schrieb address@hidden:
>> On 06.05.2015 14:09, Scott Hannahs wrote:
>>> On May 6, 2015, at 05:07, address@hidden wrote:
>>>> On 06.05.2015 10:27, address@hidden wrote:
>>>>> OK folks, this software is truly DANGEROUS. The command line is 
>>>>> incredibly obscure and counter-intuitive, …<Rant>
>>>>> even big corporations, still simply make fucking tar archives.
>>>> 1. work on your manners, please.
>>>> 2. use duply, if the command lines are too complex for you.
>>>> 3. and most importantly, as a feature duplicity does not delete or 
>>>> overwrite anything on your local filesystem during a restore. it will 
>>>> complain that the tatget exists and fail. that's why you always have to 
>>>> restore to a temp location and mv it manually from there.
>>>> regards.. ede/duply.net
>>> A remarkably good response!  Thank you.
>> thanks.. because i try to give the benefit of the doubt to everybody i 
>> quickly doublechecked the 'duplicity overwrites' statement. for a file 
>> restore using --file-to-restore . the somewhat surprising results were
>> A. object to restore is a file, target is an existing file
>> 'Restore destination directory tmp/test already exists.
>>  Will not overwrite.'
>>  although not specifically mentioned in the output _nor_ the manpage, using 
>> --force will overwrite it!
>> B. object to restore is a folder, target is an existing file
>>  behaviour same as A. , although it fails as it does not replace the file 
>> with the folder. shows errors like
>> 'Error '[Errno 20] Not a directory: 'tmp/test3/duply_/INSTALL.txt'' 
>> processing duply_/INSTALL.txt'
>> C. object to restore is a file, target is an existing folder (given w/o a 
>> trailing slash)
>>  no warning, for empty folder
>>  same as A., _note_ that a folder is replaced by a file here
>> D. object to restore is a folder, target is an existing folder (given w/o a 
>> trailing slash)
>>  no warning, for empty folder
>>  warning, overwritable via --force when folder contains files. result is a 
>> mix of old and restored content.
>> in conclusion, we should probably address that ;( 
>> ..ede/duply.net
> Ede,
> first I thought I'd understand everything above, but now having a few
> free days and reading the whole over again in leisue, nevertheless doubt
> comes to me.
> I do not see any difference in A-to-D behaviour of duplicity. None of
> the existing objects is overwritten when the --force option isn't
> applied ?! But unsolicited use of --force wouldn't warn the user :-o
> Talking about the effects of --force should be thought over again, I
> agree to you. The fact that using --force overwrites single files (after
> occurred warning) seems safe and rather logical. The behaviour in the
> case (C.) seems to be programmed inconsistently, although I would like
> even more comments from you. Guess, this made duplicity wipe the root ?
> Would be possible to simply copy those 8 commands, introduced with your
> examples including results, from your terminal to the list ? I am not
> yet clear with the critical cases as you provoked them.

hey Thomas,

not sure what your question is here. the inconsistencies discovered are
- undocumented overwriting via --force switch
- no warning for empty folders

we should decide either to document what the --force switch does for the 
restore action or remove overwriting altogether. but the the only useful 
scenario, merging into a folder would be disabled as well.

i am inclined on hacking the need for a two times --force parameter, like so
1. warning with the hint to use --force
2. are you really sure? hint to use --force --force
3. running it _and_ print out notices when files/folders get overwritten

@Ken: what do you think? 


reply via email to

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