Re: [Duplicity-talk] duplicity overwrites on restores .. Re: Duplicity wiped out my server

[Kenneth Loafman]

I think that the 2x is not a good idea, one is enough.

A prompt in this case, if there is a stdin, would be a good idea.

I think a simple "I refuse to replace the filesystem '/' with the regular file 'foo'." and a message to remove '/' if they wanted to proceed would have done the trick in this case.  No user, I think, would have removed '/'.  Generically, I would say that we should not replace a directory with a file or any other mix like symlink and regular file because that's probably an error indication, but we should never even try to replace a mounted filesystem.

...Ken

On Mon, Jun 8, 2015 at 11:20 AM, <address@hidden> wrote:

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?

..ede/duply.net