[PATCH] Local backend should always try renaming instead of copying

[Horst Schirmeier]

The local (file://) backend should always try renaming files before copying them and deleting the source file afterwards. This significantly speeds up the backup process if TMPDIR and target are on the same file system, and I wouldn't know of any disadvantages.

[Kenneth Loafman (kenneth-loafman)]

Thanks for the patch!

[Rob Wouters (78luphr0rnk2nuqimstywepozx-launchpad)]

This patch introduces a warning when the archive-dir and the local backend is on the same filesystem. LocalBackend.put() moves the file when called from Fileobjhooked.to_remote() after with that function tries to unlink the just removed file resulting in a warning being logged:

    Unable to delete /data/backup/.local_cache/duply_duply/duplicity-full.20110818T032852Z.manifest.gpg: [Errno 2] No such file or directory: '/data/backup/.local_cache/duply_duply/duplicity-full.20110818T032852Z.manifest.gpg'

Hopefully this is clear and reproducable. If not I'll provide more info.

[Horst Schirmeier (horst)]

Confirmed. Sorry, seems I didn't test this thoroughly enough.

Simple fix: Remove the warning output from dup_temp.py / to_remote().

Advanced fix (see attachment): Add a move() function to the backend interface, let it default to a call to put() + source_path.delete() (for all backends that cannot do this properly), and override it in the localbackend.

(In hindsight, backend.move() could completely *replace* backend.put(), as currently all uses of put() delete the source file afterwards.)