-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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: Unix-like symbolic links #17669
Comments
I honestly don't see the need - in addition the RFC appears experimental for a long time. But maybe somebody is willing to catch this and give the implementation a try. THX |
The need is simple, really. I use owncloud, not for storing movies or photos, but rather to act as a cached network drive. And on this "cloud" drive, I store development projects, development environments, as well as the preference files (aka. "dot-files") of several programs for which I wish to have the same settings on all machines (eg: same Geany or Skype or Gftp settings). This is a very Linux-centered usage, and symbolic links are not rare at all, nor are they always dispensable. As for the RFC, it is indeed experimental, but still better than nothing. |
i like the use case and i would love to see this works with ownclud, which will be turned in a synced preference manager… 👍 |
closing in favor of #6771 |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
First, this is NOT about transparently following links because files would be already laid out as wanted. As pointed out elsewhere, that feature is covered client-side by the configuration, and server-side by the external storage options.
My feature request is about being able to store Unix-like symbolic links on owncloud.
Synology did this by having a convention for naming links (
l_*
), much like Windows does with its*.url
files.In my opinion, this should be avoided, because whatever convention we choose, we may encounter files that conflict with this convention by having their name look like a symlink's name.
I suggest that RFC4437 should be used instead, especially since some clients on Linux and Windows seem to implement this RFC already.
I cannot speak for others, but my need would be both:
The text was updated successfully, but these errors were encountered: