Clarify config option name "Copy links (dereference symbolic links)"

Bug #706656 reported by GeorgeB
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Back In Time
Fix Released
Undecided
Unassigned

Bug Description

The advanced option "Copy links (dereference symbolic links)" may appear to be contradictory or counter intuative to people who don't immediately recognise that dereferencing links means copying the file contents; at first sight it appeared that this option needs to be checked to preserve symlinks (especially if the user is used to this not being the default e.g. in plain rsync).
My suggestion would be to rename it to something like "Do not preserve symlinks" as this is more immediately clear to familiar with having to manually choose to preserve symlinks, showing that backintime treats symlinks properly by default.

Also maybe consider a better explaination (maybe add a tooltip) for "Copy unsafe links (works only with absolute links)" to make its effects clearer to intermediate users, as it is a user may have to refer to the rsync man page to work out exactly what it means (I am assuming that the options are consistent). Maybe a tooltip like "Do not preserve symlinks which refer to files outside the backup".

Or alternatively how about replacing the two checkboxes with a dropdown selection (since theres no point enabling both that I can see) along the lines of;

"Copy file contents instead of preserving links" (with tooltip "*Warning* this may create infinate sized backups if you don't know what you are doing.")
With the options;
-Never (default).
-Where the link points outside the backup.
-Always.

This is from latest version of backintime-kde4 from the stable ppa.

Revision history for this message
Γουργιώτης Γιώργος (aka Gourgi) (gourgi) wrote :

agree
the first think i've thought was that it provided "preserve symlinks"

Changed in backintime:
status: New → Confirmed
Revision history for this message
Dan (danleweb) wrote :

Well this options are in "expert tab". If someone don't understand it maybe this tab is not for him.
I prefer this messages because this are used in rsync man (since BIT use rsync).

Regards,
Dan

Revision history for this message
GeorgeB (solar.george-deactivatedaccount) wrote :

I know that it is the experts tab, I still think that's no reason not to make it clear when alternative phrasing would be more immediately clear.
I like that backintime does preserve symlinks by default but when most other rysnc based programs that I've come across don't do so and may put "copy links as links" or similar as an advanced feature (e.g. grsync) it appears to anyone not familiar with the terminology you use (doesn't mean they wouldn't understand what the option does if it was worded differently) the BIT has followed the same approach and you must select that option in order to preserve symlinks.

The issue is not so much with people using the experts tab when they shouldn't but with wording that might cause intermediate users to change an expert option if they happen to notice it (and the problem may not be immediately obvious unless they've got recursive symlinks inside the backup just things not working when they try to restore).

While the phrasing obviously make sense to you since you must have a fairly extensive knowledge of rsync to make something like BIT work, the program itself appears to be aimed at basic/intermediate computer users. While the former won't fiddle with the "Expert" options intermediate users may well be used to checking for odd default choices or needed to enable symlink preservation and get caught out by the wording.

You mention that "dereference" is used in the rsync man page but I can't find any use of that word on my system (Ubuntu 10.10);
man rysnc
. . .
        -l, --links copy symlinks as symlinks
        -L, --copy-links transform symlink into referent file/dir
            --copy-unsafe-links only "unsafe" symlinks are transformed
            --safe-links ignore symlinks that point outside the tree
. . .
       -l, --links
              When symlinks are encountered, recreate the symlink on the destination.

       -L, --copy-links
              When symlinks are encountered, the item that they point to (the referent) is copied, rather than the symlink. In older versions of rsync, this option also had the side-effect of
              telling the receiving side to follow symlinks, such as symlinks to directories. In a modern rsync such as this one, you’ll need to specify --keep-dirlinks (-K) to get this extra
              behavior. The only exception is when sending files to an rsync that is too old to understand -K — in that case, the -L option will still have the side-effect of -K on that older
              receiving rsync.

       --copy-unsafe-links
              This tells rsync to copy the referent of symbolic links that point outside the copied tree. Absolute symlinks are also treated like ordinary files, and so are any symlinks in
              the source path itself when --relative is used. This option has no additional effect if --copy-links was also specified.

       --safe-links
              This tells rsync to ignore any symbolic links which point outside the copied tree. All absolute symlinks are also ignored. Using this option in conjunction with --relative may
              give unexpected results.
. . .

Revision history for this message
Francewhoa (francewhoa) wrote :

+1 to clarify that config option name. I would be happy to contribute testing.

Revision history for this message
Francewhoa (francewhoa) wrote :

I just created a related ticket at https://bugs.launchpad.net/backintime/+bug/1335654

Revision history for this message
Germar (germar) wrote :

I added tooltips with snippets from 'man rsync' in 1.1.0

Changed in backintime:
status: Confirmed → Fix Released
Revision history for this message
Maximilian Lang (lang-maximilian) wrote :

(MAYBE HELPFUL COMMENT FOR SOME ON HOW TO COLLECT THE PATHS OUTSIDE THE BACKUP-TREE MORE EASILY TO ADD THEM MANUALLY TO BIT)

So this is how these 2 options that kept me busy came into existence..!

I have finally accepted that I have to add the locations outside the backup-tree manually. It didn't work no matter what I did (BIT went into eternal loops) and I suppose there is good reason this functionality isn't featured.

BUT: how does one "quickly" find all paths that need to be added manually then because one has softlinked them ages ago?!

Here are 3 good quick options for terminal commands that do just that - print all those locations (running recursively through the directory you're at -usually that's your home directory when you have opened a new terminal):

symlinks -vs -r .

(mind the necessary dot! If not installed, install symlinks via sudo apt-get install symlinks)

More options:

find . -maxdepth 10 -path ~/.local/share/Trash -prune -or -path /ANOTHER/PATH/WITH/NUMEROUS/IRRELEVANT/SYMLINKS/YOU/DONT/WANT/LISTED -prune -or -path /YET/ANOTHER/SUCH/PATH -prune -or -type l -exec readlink -f '{}' \;

(one line. Here you can play mith -maxdepth, e.g. try maxdepth 2 etc. Remove all instances of
'-path /BLA/BLA/BLA -prune -or'
that you don't need! Or add more of them, respectively)

If you leave out everything starting from -exec and add -print, e.g.

find . -maxdepth 10 -path ~/.local/share/Trash -prune -or -path /ANOTHER/PATH/WITH/NUMEROUS/IRRELEVANT/SYMLINKS/YOU/DONT/WANT/LISTED -prune -or -path /YET/ANOTHER/SUCH/PATH -prune -or -type l -print

you get the locations of the symlinks themselves instead of their referents, in case you need them.

A BIT OFF-TOPIC: you can find all "dead" symlinks that are currently not pointing anywhere via

find . -maxdepth 10 -path ~/.local/share/Trash -prune -or -path /ANOTHER/PATH/WITH/NUMEROUS/IRRELEVANT/SYMLINKS/YOU/DONT/WANT/LISTED -prune -or -path /YET/ANOTHER/SUCH/PATH -prune -or -xtype l -print

Best regards,
Max

Revision history for this message
Maximilian Lang (lang-maximilian) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.