New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Symlinked files [$20] #6771
Comments
yeah, symlinked files and folders kept as regular files and folders is a must have feature on CLIENT side |
Since this is something for the client side, please submit your request in the mirall repo. |
I am not sure of the technical aspects of the issue here. They said they can't do it because the server does not support it. And you say it is a client side issue. Can you both be a little more specific about the technical limitations to implement this feature? I would love to see both opinions in a single thread. =) |
Haha, right. I think there are at least two ways to implement symlink support.
They probably meant number 1) which means the server should have means to create symlinks. However, solution 2) should not require server changes. In that case, the client would dereference the symlinks which means just upload their contents instead of the symlinks themselves, as if they were regular files (which the server understands) Does that make sense ? |
@danimo why do you need the server to store symlinks? Actually I think the best (or at least the expected) behavior is what dropbox does which is, it just copies the files as if they were actually there. Can you elaborate? |
@salinasv Depends a bit of what you expect. Keeping symlinks verbatimly is nice if you want to use ownCloud as a backup solution, which was requested elsewhere. You can always make that configurable of course. |
in my case I just want the client upload symlinked file or folder just as if they were there like danimo said |
+1 for symlinks |
+1 for symlinks (on the client, just upload as regular files to server) |
+1 for dereferenced symlinks (like dropbox) |
+1 for Dropbox-like dereferencing. |
+1 for dereferenced symlinks (like dropbox) |
+1 for dereferenced symlinks (like dropbox) |
As requested to be transferred here from #7954 . Some of the users above would like the symlinks to be dereferenced client side and propagated as normal files to the server. This approach can lead to some strange behavior, but I understand the rationale behind this, and this bug report is about this requested behavior. On the other hand, for people using owncloud as a backup solution, just propagating the symlinks as symlinks to the server is enough. I understand that some ways to access the files do not support these files, e.g. webdav, and for these cases, the symlinks can be indeed ignored. But using a more feature rich client should be able to use this extra feature. I guess the best solution is to have a (off by default) flag that enables this behavior. |
+1 on de-referenced symlinks As @andrikos says, it should be an option in the client to either
|
+1 on dereferenced symlink |
1 similar comment
+1 on dereferenced symlink |
+1 on symlink syncing to the server. Symlinks are important to keep, especially on OS X where bundles (like an app) typically contain symlinks inside (the user may not even be aware of it). Dereferencing symlinks would be an unnecessary duplication of files. Dropbox is using Symlinks in a weird way to sync files outside the synced directory (which I think should be questioned to do at all, actually the symlink of the outside location should point into the synced directory) |
+1 for dereferenced symlinks (like dropbox) |
+1 also from me |
I believe this is not on the roadmap at the moment, but if anyone of you guys can code and would provide a proof of concept pull request (with "WIP" tag), it might help push the case a bit 😃 |
+1 for dereferenced symlinks (like dropbox). I think User data rarely contains any symlinks, so the simplest approach would be to dereference symlinks inside the ownCloud Folder and ignore any symlinks further down. No recursive loops or duplicated data possible (except for duplicated links in the ownCloud folder). I imagine the common use case to be the synching of user data rather than the synching of whole harddisks with application data on them. |
+1 for symlinks, this would allow a lot of people to use Owncloud as a backup server and as a replacement for Time Machine |
+1 for dereferenced symlinks (like dropbox) |
+1 for symlinks (like dropbox) |
+1 for dereferenced symlinks |
+1 for dereferenced symlinks. In fact, I suppose that this might be a sane way to handle hard-links, as well (or make this configurable; I believe Dropbox does the same for hard- and symlinks). |
Another use-case where symlinks are needed is when an application re-creates config files instead of writing in-place. The route of symlinking the regular file from the Owncloud folder into the application config folder (say, ~/.config/foo) won’t work then, since the application will delete the symlink and write out a regular file. (This might be considered a bug on part of those applications, but it seems to be rather common.) |
+1 for dereferenced symlinks |
+1 |
https://www.bountysource.com/issues/1381302-feature-request-symlinked-files in case it helps finding some volunteers to build a proof of concept. |
meanwhile use lsyncd |
+1 on symlinks - anyone in the *nix world makes heavy use of them... no syncing symlinks is a big issue. |
this list getting bigger and bigger but I have an unclear feeling that authors still refuse to implement symlinked files so what's the point for voting anyway? |
From all the people voting here many seem to have coding skills (many repositories/forks). So why not make a proposal PR ? It doesn't have to be a finished solution, but a good base that can be improved incrementally. Questions like:
|
Once all these questions are addressed properly, we'll already be a little step closer to a solution. |
Sorry for mentioning, but dropbox handles the symlinking rather well imho. Could we learn from how they're handling it? |
I just want to make it clear that ownCloud is an open source project with a completely open development process. Everybody can help and is welcome to submit a code change for this feature. No one is refusing to implement anything. But more help is needed to move forward. |
+1 for dereferenced symlinks |
Since apparently no-one is able to read what we mentioned already a few times: "+1 does not help except annoying devs" this issue is now locked to contributors only. |
For the Webdav nodes, could use redirect refs: https://www.ietf.org/rfc/rfc4437.txt. |
Feature request: The ability to symlink files in the Owncloud synced folder on the local computer.
as per this discussion at github/owncloud/mirall: owncloud/client#665
This is possible in Dropbox:
(see: http://lifehacker.com/5154698/sync-files-and-folders-outside-your-my-dropbox-folder)
Purpose: to allow a more unified collection in the Owncloud sync folder, and including files from other directories. This is standard feature in Dropbox, and users accustomed to working under this paradigm might expect the same functionality.
Here's a few comments from users in that thread requesting this support:
The moderator Danimo in that thread responded it's impossible, and to open a feature request in core:
Thanks for your hard work, devs, and will appreciate any consideration of this idea. Awesome application.
The text was updated successfully, but these errors were encountered: