Repository navigation
Syncing symbolic links as reference #250
Description
Currently when I add a symlink inside my Nextcloud folder it doesn't sync because "Symbolic links are not supported in syncing".
I am trying to use Nextcloud as a home for my data, to have it synced between my PCs. Now I'd also like to be able to access my git-repositories (mostly) code via the directory-structure in Nextcloud but I don't want to sync the git-repositories via Nextcloud. This is why it would be really nice for me to be able syncing only the link to the repository which is on a fixed position on any system. eg: ~/Nextcloud/current_projects/fizzbuzz would point to ~/repositories/fizzbuzz.
If I happen to be on a system where this git-repository isn't present I can just clone the repository there.
This option could be optional (like the syncing of hidden files).
There's also a issue about this for the owncloud-client here: owncloud/client#1440
Activity
camilasan commentedon Apr 17, 2018
I see the use case, but we also would have to deal with windows links on mac, mac links on Linux... you get the drill. So between confusion and technical difficulty, and adding that most users don't even use symlinks all that much, this mostly seems a low-priority thing for me. Of course, anyone is free to work on it but he/she will have to do a full (cross-platform) solution, and that won't be easy.
camilasan commentedon Apr 17, 2018
For reference: https://help.nextcloud.com/t/symbolic-link-support/220/27
david-jointech commentedon Apr 17, 2018
Would the proposed implementation in point three of this post https://help.nextcloud.com/t/symbolic-link-support/220/18?u=callegar be a viable way to solve the problem?
ferdiga commentedon Apr 17, 2018
I agree with the arguments mentioned in the link above.
a symbolic link is a very useful way (especially on Linux) to extend local storage capacity using other partitions and / or disk. at least on Linux the nextcloud client shouldn't exclude links as these are transparent to all Linux programs
nefelin commentedon Sep 5, 2018
I understand the difficult involved but I would love to see a solution to this. Or at least an option to sync links across compatible platforms...
I use symlinks to sort a very large image collection that I use for drawing practice into smaller collections, which lets me have image sets exist in multiple collections, it is very useful and intuitive but would be even better if it synced.
m1cm1c commentedon Sep 20, 2018
Are you saying that if Nextcloud were to support symlinks, it would have to be able to convert them to
*.lnkfiles on Windows? Converting between symlinks and*.lnkfiles is impossible in either direction, simply because you can't find a generic way of converting between paths on Linux and paths of Windows in either direction. Why not simply only create symlinks on the other system if it's also a Unix-like system? You can't unify Windows with the rest. They chose to be fundamentally incompatible with Linux / Mac / FreeBSD / OpenBSD / Solaris / whatever.On the windows client, you can choose between:
I suppose you currently just dump Windows'
*.lnkfiles as what they are on Unix-like systems, even if they are of no use there (well, they hardly are of any use on Windows too because they can't be used in the middle of paths, but that's a different topic).fwsGonzo commentedon Oct 7, 2018
No one is asking for conversion between symlinks and "windows links". There is no one-to-one comparison anyway. The dream solution here is to just not care that you found a symlink on linux and just treat it normally. If its a folder, its just a folder - extending storage. I can`t understand why the nextcloud client is hindering this to begin with, as you would have to actively disallow it.
EDIT: This is actually making it hard to use this cloud for me at all. I absolutely needed this feature to work exactly like Dropbox (and others).
piranhaphish commentedon Oct 11, 2018
I agree that this is needed. I would go as far as to say that ignoring symlinks is a bug. Like was mentioned above, a symlinked file/folder can simply be treated as a normal file/folder; you have to intentionally go out of your way to avoid doing so (by using
lstat()instead ofstat(), for instance).I don't think anybody is asking for the symlink itself to be represented on the cloud-side, moreso just simply recognized by the client side.
david-jointech commentedon Oct 12, 2018
I actually was asking for symlinks to be synced as "symlinks" and not to sync the content. The main reason for me is that I want to work out of my nextcloud-directory by default (I have an organization system in place there) but I do not want to sync git-repositories via nextcloud.
AncalagonTheBlack commentedon Oct 31, 2018
Such a Feature would be awesome. So many times it would come handy and today again.
alexeymuranov commentedon Nov 27, 2018
I've noticed some seemingly random behaviour of my nextcloud-client 2.5.0 on Ubuntu (installed from
nextcloud-devsPPA) with respect to symlinked folders inside a synchronised folder.I first noticed that files in some local folder
Awhich was not synced itself, but was symlinked from inside a synced folderS_localseemed to have disappeared by themselves. I looked into it and found that in the local synced folderS_locali had a symlinkAto the "external" folderA, but in the remote synced folderS_remotethere was an actual non-empty subfolderA(with the same name) in that place. When trying to sync, the nextcloud client was simply wiping the contents in my local folderA(which was just symlinked from insideS_local), and it was not downloading anywhere the contents of the remote actual folderA.So far i didn't manage to reproduce this behaviour with a fresh folder (but i can reproduce it in the
Afolder). However, i observed some other strange behaviour. For example, i have currently a symlink to a folder locally, but a real folder with the same name remotely, and their contents is only partially synchronising.Is this related to any known bug? I am not ready to report it myself, because i cannot yet reproduce the file-eating behaviour from scratch.
63 remaining items
taminob commentedon Aug 22, 2024
I don't think the discussion here will reach the server team who rejected it because of inter-OS compatibility (see nextcloud/server#41321 (comment)). I'm actually also fine with having this feature as a server app so that you manually have to enable it - as long as it can be used, I'll be happy (Linux users are usually used to things not working out-of-box :| ).
I'm currently stuck because I'm waiting for feedback on the desktop client PR (see #6205 (comment)) if it would be possible to include it even though it's "just" an app (similar to the E2E encryption which is also an app and included in the desktop code base).
f1d094 commentedon Aug 22, 2024
I don't care if I have to stand on 1 foot, pat my head, and rub my tummy while whistling the Star-Spangled Banner… whatever it takes. All of our systems are highly customized. One more mod would be a raindrop in the ocean.
Good luck getting anyone to actually work with you.
jellyterra commentedon Oct 8, 2024
If it is not compatible with Windows, JUST make it available on Mac and Linux. 😅
Don't throw the baby out with the bathwater.
taminob commentedon Oct 8, 2024
That argument came from the server maintainers and I don't think they read issues in this repository (if any Nextcloud team member looks into this issue at all anymore).
But I'll probably be too busy for this for the next 12 months anyway, so don't expect any progress in the near future.
If anyone else wants to continue the work in the meantime, feel free to reach out to me and I'll provide help with the existing changes as far as I can (not that I recommend the contribution experience without getting paid :) ).
doctorscott commentedon Oct 17, 2024
Supporting symbolic links should be incredibly easy, even on Windows! It is just a file that has a resolvable path. Well, it is a slightly bit more than that, but still. Right now, it converts working directory symbolic links to hard links or just an empty directory. Again, this should be easy! On windows, create a symbolic link with: mklink /d "link" "target". Try this and sync and look on another computer that is synced. It is not even close! Honestly, this is not really a feature request, but a bug fix request.
RuizuKun-Dev commentedon Dec 17, 2024
would be nice to have support for this, non of the Cloud Storage software do unfortunately
ikcalB commentedon Dec 26, 2024
+1
all OS support links.
option to use OS defaults, make plain text file, file with original link path / etc. are all feasible - imho the only question is about a (sensible) default?
SchroedersKater commentedon Dec 31, 2024
There is also another good reason for symbolic links here.
taminob commentedon Jan 1, 2025
Here is a short summary for everyone who doesn't follow the PRs and also doesn't want to read this entire issue discussion:
-> this approach got the approval of the desktop app maintainers quite recently
So we are on a good way to actually get this done, but the remaining development efforts will be:
I personally won't have enough time for this for the next couple (~10-12) of months, but will try to get this done as soon as I find the time to spare. If anyone else wants to give it a try in the meantime, feel free to write me so that I can give you some more context for the current state of the PR changes.