|
From: | Aaron Whitehouse |
Subject: | Re: [Duplicity-talk] duplicity overwrites on restores .. Re: Duplicity wiped out my server |
Date: | Sun, 17 May 2015 14:53:01 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
Hello all, On 06/05/15 15:22, Russell Clemings
wrote:
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 That sounds sensible to me. Seems sensible, that is a bizarre thing to do intentionally. With or without a trailing slash, behaviour should be the same in my opinion, and the file should be restored into the folder specified. 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 |
[Prev in Thread] | Current Thread | [Next in Thread] |