![]() ![]() When some code is stored in a directory structure, symlinks may be used to assure that the makefile finds things where they are expected to be. When certain spreadsheets are stored in a directory structure, they assure that linked spreadsheets are found where they are expected to be without duplicating files on the client. Furthermore, when certain LaTeX documents are stored in a directory structure, they are functional to assure that LaTeX then finds things where it expects them to be, without having to duplicate files. To me symlinks support is critical to the storing and sharing of stuff in next cloud, because they are a part of how data is made accessible and searchable in large directory structures. Then, the other way round, when getting something that is on the server, but not on the client, recognize if the item to be synced is a file whose content matches the symlink magic, and (i) if so and (ii) if on a platform supporting symlinks, change the file on the client into a symbolic link. bar.txt, I would be happy of seeing on the server a foo.txt file with content symlink ->. For instance, if I have a symbolic link, such as foo.txt being a symbolic link to. Recognize the existence of a symlink on the client host and store it in the server as a file.To me, it would be OK to have the sync client I know that not all platform support symlinks equally well. With no dereferencing, symlinks cannot be a security risk. I am interested in storing symlinks “as they are”, with no dereferencing what so ever. In talking about symlinks, I am not interested in them in view of using nextcloud as a backup strategy. I would like to know if there is any news on the state of symlink support wrt the sync client. Building symlink support in will also allow Nextcloud to understand symlinks that come in from External storage providers. It’d be a great feature to have and might open up some new possibilities for how Nextcloud can be used. Other apps - notably git - are making use of these and now that NTFS’s support for symlinks is more public its usage will only increase under Windows. The only vector this doesn’t handle is loops: If some malicious user creates an infinite loop of symlinks the apps reading this on the client’s operating system should handle this anyway, as these could be created on systems not running Nextcloud. I believe these will avoid most security issues, including the /etc/passwd suggestion above. symlinks have to point to other files inside your Nextcloud data dir (which to me means relative links only, and no use of ‘…’ to escape the data dir) - so the server would necessarily need to validate this when a new link is uploaded/modified on the server.no dereferencing server-side, only client-side.Can I make some implementation suggestions: Symlinks may seem like a gimmick but for some of us they’re hugely useful. ![]()
0 Comments
Leave a Reply. |