duplicity-team team mailing list archive

[Will Storey <will@xxxxxxxxxxxxx>]

The proposal to merge lp:~horgh/duplicity/copy-symlink-targets-721599 into lp:duplicity has been updated.

Description changed to:

Hello,

I recently started using duplicity. I have a directory with many symlinks in it. I was hoping to be able to back the data up while dereferencing the symlinks as that is easier for my use case.

I see there is a bug report requesting such behaviour: https://bugs.launchpad.net/duplicity/+bug/721599

I understand why by design it would be acceptable to not dereference symlinks, but I think it can be useful to provide a flag to do it.

My solution is to add a flag called --copy-links. rsync has a flag with this name so that is why I picked the name. This is rsync's brief description for it: "--copy-links transform symlink into referent file/dir".

I found that it was sufficient to change the os.lstat() call in path.py to os.stat() when this flag is enabled so that duplicity no longer actually sees symlinks. I did wonder if this is an acceptable place for it though, as path.py seems fairly low level to be worried about globals. But I saw elsewhere in this file and class that we access globals.

I've found that backup and restore behaviour works fine in manually tests with this update. If I run a second backup without the flag given, then the backed up version updates to hold the symlink, and vice versa.

I've not updated any documentation or anything yet as I thought I should get feedback whether this will be acceptable, and whether this approach is okay.

Please let me know if you have any thoughts on this or improvements I can make.

Thank you for your time!

For more details, see:
https://code.launchpad.net/~horgh/duplicity/copy-symlink-targets-721599/+merge/312438
-- 
Your team duplicity-team is subscribed to branch lp:duplicity.