Repository navigation
Preserve symbolic links on local storage聽#29915
Description
How to use GitHub
- Please use the 馃憤 reaction to show that you are interested into the same feature.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Is your feature request related to a problem? Please describe.
I'm always frustrated when i try backing up symlinks using docker-compose exec --user www-data app php occ files:scan --all because it go to location of file and scan it instead of uploading the symlink as is (text file with location of real location?)
Describe the solution you'd like
treat symlinks as textfiles maybe and upload them?
Describe alternatives you've considered
I enabled backup up links in my config.php ('localstorage.allowsymlinks' => true,)
Additional context
My use case is backing up my files (including .wine dir which uses sym links in z:\ that leads to my root dir)
Activity
[-] Treat symoblic links as files #29910 [/-][+] Treat symoblic links as files [/+]joshtrichards commentedon Aug 27, 2023
Are you referring to uploading symbolic links that exist on the client side and maintaining them as symbolic links within NC?
Note that Nextcloud isn't a backup solution. Syncing the target of a symbolic link as a file (as it currently functions), sure. But client-device symbolic links aren't really a concept that can be mapped from another device. The "real location" only exists on your original device. For relative symbolic links, where all the targets are also hosted within your sync'd folders, maybe I can see that. But any targets of symbolic links outside the already sync'd folders would just be inaccessible from any other device (including the NC Server).
[-] Treat symoblic links as files [/-][+]Preserve symbolic links[/+]f1d094 commentedon Mar 10, 2024
@joshtrichards Syncing the target of a symbolic link as a file is absolutely the incorrect approach for symbolic links. They should be copied as-is, unmolested. The current behavior is destructive, unexpected behavior that interferes with the normal function of the FS and OS on all *nix operating systems. Nextcloud should not be replacing 0byte items with duplicate files.
With proper, un-molested implementation of symlinks, inter-operating system compatibility should not be an issue. For any client-OS that does not support symlinks, the client should simply ignore them. Server-side, they could be special files that simply describe where they normally point allowing for server-side deletion if desired, but no creation or modification.
When they are server-side or sync'd to another client, it should not matter if they are "broken" and point to nothing. This is common and expected by the end user. Whether or not symlinks can be mapped from another system is also irrelevant. It is up the end-user to have similar file-systems on the various sync'd clients if they want those symlinks to work...or not. It is not Nextcloud's place to be making that decision on the user's behalf, making unexpected changes to file or the filesystem.
There are two PRs on this now to restore correct behavior of symlinks. PR#41321 and PR#6205
[-]Preserve symbolic links[/-][+]Preserve symbolic links on local storage[/+]