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

[Aaron Whitehouse]

Hello all,

On 06/05/15 15:22, Russell Clemings wrote:

FWIW, this almost sounds like a documentation issue to me.

I'm not sure that the behaviour here is intuitive. If it isn't, I don't really like trying to solve the problem with documentation and would rather try to make the command more intuitive (or at least safe, if it is ambiguous).

If I:
$ cp testfile.txt /tmp/test/
I end up with /tmp/test/testfile.txt

Why shouldn't:
$ duplicity --file-to-restore www/foobar.com/blah.html s3://amazon.com/foobar /
automatically restore the file to /blah.html in the same way as cp? I can't imagine anybody wanting to automatically replace a folder with with a file in that way, and if they do then they can do it once the file has restored.

> 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!

That sounds sensible to me.

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'

Seems sensible, that is a bizarre thing to do intentionally.

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

With or without a trailing slash, behaviour should be the same in my opinion, and the file should be restored into the folder specified.

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 ;(

I would have thought that the safest behaviour here was to restore the folder to be restored into the target folder, so:
$ duplicity --file-to-restore www/foobar/source_dir s3://amazon.com/foobar /target
led to source_dir being restored to /target/source_dir - I can see both sides of this argument, however.

Just my 2c.

Kind regards,

Aaron