(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 …
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.
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.
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
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.
2021 and this is still a problem. I have the same issues as described above – a Final Cut Pro X Library triggering a recursive loop.
It’s really weird to have a default symlink behavior like this, and it should definitely be possible to turn it off. At least in the pro version or on the server side, if client-sided is too much work.
No other cloud syncing tool, whether commercial or self-hosted, does this – and with good reason. I can’t understand that decision and I’m pretty frustrated that this issue has been ignored by the devs for about 8 years now.
seafile-ignore.txt can help you with this. Remvoing this feature (it’s hard to believe that traversing the fs as is should be considered a feature) would cause problems for me and I’m sure other users too. Having an option to disable it per-library, or maybe having something inside seafile-ignore.txt to signal this behaviour should be disabled, should be the way to go, otherwise you’re just deciding who’s setup you’re going to break instead of fixing it for everyone.