symlinks not supported

[ukos-git]

bug description

Linux Desktop Sync Client (v2.3.3, ubuntu repo) states

Symbolic links are not supported in syncing.

In fact, if I manually copy a (relative) symlink to the files folder, there is a problem with the Windows Sync client (which - of course - can not recognize the symlink and overwrites the file on changes.)

The Linux Desktop Client, therefore, does not upload any symlinks.

wanted behavior

sync symlinks so that i.e. git annex repositories can be synced.

security concerns

In my opinion, there is no need for restrictions for symlinks as long as they are relative to the current directory and do not point outside of the user's directory.

code discussion:

There was a notice from @cryptomilk in d5aced8 that was deleted by @dragotin later on in d943b28.

-    case CSYNC_FTW_FLAG_SLINK:
-      /* FIXME: implement support for symlinks, see csync_propagate.c too */

In his commit @cryptomilk states that symlinks need "a lot of work" and are therefore skipped here. @dragotin gives no reason why he removed the FIXME If FIXME is now deleted, symlinks will never be supported, right? What if I am aware of the Windows Sync Client overwriting the symlinks and for me this is totally ok when syncing symlinks. I can not imagine why it should not be implemented.

[ukos-git]

I am not sure where exactly the files are exclude in the linux desktop. The exclude procedures in csync/csync_exclude.c and windows and unix differentiation are quite complex.

As I see it, the CSYNC_STATUS_INDIVIDUAL_IS_SYMLINK is flagged in csync/csync_update.cpp if fs->type == ItemTypeSoftLink.

Somewhere also a ignore instruction is set fs->instruction == CSYNC_INSTRUCTION_IGNORE to trigger the error message at https://github.com/nextcloud/desktop/blob/master/src/csync/csync_update.cpp#L404
I think there should be an instruction like CSYNC_INSTRUCTION_NONE for symlinks somewhere in previous code instead of the IGNORE flag but I cannot find where IGNORE is set for symlinks.

[jancborchardt]

This is a duplicate of #250 – let’s continue there. :)