Symbolic link support

ℹ️ Support
22

Please take care here:

there are 2 ways in which symlinks can be supported with a cloud storage sync system.

  1. The first one is to store the link without ever dereferencing it.

    • It is the approach asked for in my previous post #18 (Symbolic link support)
    • It is by definition totally safe, can be supported on a per-client basis.
    • Can be useful to users who use symbolic links as a way to organize stuff and provide shorthands within document sets organized with an internal directory structure or that must obey specific rules about where things must be found (LaTeX projects, source code, linked spreadsheets, etc.)
    • It should be relatively easy to implement.
    • It is consistent with what popular software like git does with symbolic links.

  2. The second one is dereferencing the links to let stuff lives outside of the directory that is meant to be synced to be synced anyway.

    • it works by providing a symbolic link to the stuff to be synced inside the directory under the control of the synchronization software
    • It implies some dereferencing, that may inherently be troublesome.
    • It is the Dropbox way of doing things. But it is at best quirky (since the sync client cannot be notified of changes happening outside the directory that is meant to be synced, which means that the sync operation cannot be reliably started right after a file is changed). There are a lot of messages on the web about this issue, and Dropbox itself discourages using it (https://www.dropbox.com/help/syncing-uploads/selective-sync-preferences-wont-update#symlinks).
    • IMHO, now that Nextcloud/Owncloud support multiple sync directories, it is not a very interesting feature, since a similar behavior can be obtained in a more robust way.

When asking about the symlink feature, I would like to recommend making clear which one of the two behaviors is being asked for. Ideally, there should be two independent feature requests for the two.

4 Likes