Re: [Duplicity-talk] Number of Files Limit?

[Peter Schuller]

> Many thanks for the help.  Can you explain (so I can remember) why
> backing up
>
>  /music/SubDirectory
>
> (where /music is a symlink) works while backing up /music does not?
> Isn't that 'following' the link?

When you ask to back up /music/SubDirectory it "follows" the /music
link implicitly, yes, by virtue of the fact that the underlying
operating system automatically supports symlinks. However, duplicity
is not concerned with /music in this case; only /music/SubDirectory.
It would not really make any sense to stop at /music because it was a
symbolic link. If tools behaved like that (cd, cp, mv, find, etc)
symlinks would be practically useless.

Now when it comes to the actual file being pointed to, or
subdirectories if it is a directory: Normally software that does some
kind of traversal tends to specifically check for symbolic links and
not follow them. This includes tar, find, rm, rsync, etc. In many
cases following links could be disastrous (such as rm -rf /path -
consider that you may have a symlink to, for example /usr or even /
somewhere). So; "rm -rf /home/scode" should absolutely resolve
"/home/scode" according to standard operating system semantics
(including following symlinks); otherwise if /home was a symlink rm
-rf would pretty much have to fail, rendering symlinks useless. But if
/home/scode/mystuff is a symlink to /, you definitely don't want rm to
follow it.

In the case of software that does backups, the correct course of
action unless the user specifically selects otherwise, is to "support"
symoblic links by preserving them. Backing up a hierarchy and
restoring it should produce an identical hieararchy; this would not be
the case if symbolic links were "followed" rather than stored as
symbolic links in the archive.

Hopefully that clears up why something like duplicity would by default
*preserve* rather than follow symlinks encountered in the general case
during traversal of a hierarchy.

Admittedly the specific case of a path directly listed on the command
line *could* be considered a special case in that it might seem
obvious that the user really wants to backup the destination of the
symlink. Here I won't claim that the correct behavior is obvious; but
my primary arguments against treating it specially would be:

* Consistency with other tools and general Unix expectation.
* Consistency within duplicity in the sense of symlinks always being preserved.

Practically, I suppose using duplicity to back up a *single* symbolic
link is a bit of a strange use case...

One might imagine a future version of duplicity supporting multiple
sources on the command line though, and it suddenly becomes more
realistic that someone might say:

  duplicity /path/to/important/files/*.stuff ....

I suppose it boils down to the "root" of the backup being part of the
backup, rather than being hard-coded as a container of other things
(i.e., a directory). Hence, if the "root" happens to be a symlink; you
preserve that symlink.

-- 
/ Peter Schuller