Seafile client shouldn't follow symlinks

(At least on Mac, if the behaviour is different on other platforms)

I just realised why my development folder, 3GB on disk, ballooned to several hundred gigabytes when synced with Seafile. For some inexplicable reason the client happily follows symlinks and backs up whatever those happen to point to as well.

This is really bad behaviour. If I want to back up other libraries than the one I selected I can easily add those - but there seems to be no way to not follow symlinks. After a quick search I found suggestions on using seafile-ignore.txt to block out the name of the symlink (adding them as files) but that does not work. And in any case, it’s an extremely bad solution. The name of a symlink can easily be the same as the name of something I do want to sync.

Please change this behaviour. As it is the Seafile client is useless for backing up a development directory for anyone who writes Mac programs. The regular way of packaging an .app in a .dmg is in a directory with a shortcut to /Applications - so that the user can do an easy drag’n’drop when installing. I have several such staging-directories in my development folder and for each and every one of them Seafile starts backing up all my applications …

5 Likes

Yes, a solution for this is needed. Some time ago a user had the following problem in his logs:

[12/20/15 20:08:10] repo-mgr.c(1211): Failed to stat /Volumes/xxx/SYNC_yoursecurecloud/Seafile/xxx/04_videos_01_xxx_xxxx/xxxxx/xxxx.fcpbundle/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache/.fcpcache: Too many levels of symbolic links.

This is also related to symlinks. Maybe the client by default should not sync symlinks but if the user wants to do this, he could use a updated version of seafile-ignore.txt, since (i think) just 1-2% really needs this.

1 Like

Hello,
I have the same exact problem with symlink on Mac ! This made impossible to sync an iMovie librairy for exemple (there is this strange symlink inside it : “.fcpcache -> .” which triggers a recursice loop). The Photos library suffers to : there are several symlink inside it resutling in a huge waste of space on the server (in my case, 91Go occupied for a 43Go library).

Both iMovie Library and Photos librairy are very commun on Mac, it’s strange there are no more reports about this symlink issue.

1 Like

+1 @daniel.pan

Please look into the issue.

1 Like

+1 at least let us choose if we want the symlink to be followed.
Thanks a lot for the hard work though!

+1.

I just had seafile generate a multi-gigabyte log file with errors like those shown below. This happened in spite of the fact that the directory containing the symbolic links was in the seafile_ignore.txt. It took me several hours to figure out why my Seafile client wouldn’t work anymore.

[03/29/18 15:59:01] wt-monitor-linux.c(525): [wt mon] fail to stat /home/johan/Seafile/main/sikando/Projects/lowist/poky/industrial-poc-build/tmp/work/x86_64-linux/acl-native/2.2.52-r0/acl-2.2.52/include/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/sys/acl/acl/sys/sys/sys/acl/sys/sys/sys/acl/acl/acl/sys/acl/sys/sys/sys/sys/sys/acl/acl: Too many levels of symbolic links
[03/29/18 15:59:01] wt-monitor-linux.c(525): [wt mon] fail to stat /home/johan/Seafile/main/sikando/Projects/lowist/poky/industrial-poc-build/tmp/work/x86_64-linux/acl-native/2.2.52-r0/acl-2.2.52/include/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/sys/acl/acl/sys/sys/sys/acl/sys/sys/sys/acl/acl/acl/sys/acl/sys/sys/sys/sys/sys/acl/sys: Too many levels of symbolic links
[03/29/18 15:59:01] wt-monitor-linux.c(525): [wt mon] fail to stat /home/johan/Seafile/main/sikando/Projects/lowist/poky/industrial-poc-build/tmp/work/x86_64-linux/acl-native/2.2.52-r0/acl-2.2.52/include/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/sys/acl/acl/sys/sys/sys/acl/sys/sys/sys/acl/acl/acl/sys/acl/sys/sys/sys/sys/sys/sys/acl: Too many levels of symbolic links
[03/29/18 15:59:01] wt-monitor-linux.c(525): [wt mon] fail to stat /home/johan/Seafile/main/sikando/Projects/lowist/poky/industrial-poc-build/tmp/work/x86_64-linux/acl-native/2.2.52-r0/acl-2.2.52/include/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/acl/sys/acl/acl/sys/sys/sys/acl/sys/sys/sys/acl/acl/acl/sys/acl/sys/sys/sys/sys/sys/sys/sys: Too many levels of symbolic links

1 Like

+1

We really need this!

1 Like

I have the same problem with backup programs unrelated to Seafile. Only work-around I’ve ever seen that was successful was putting the symlinks in an exclude list.

I’ve reported this problem previously. Hopefully this will be improved soon.

Here https://github.com/haiwen/seafile/issues/288 is issue about adding symlink support in Seafile with provided two solutions.