Mounting files

[stag-enterprises]

I think it would be nice to have the ability to mount files (or folders), so that they would be accessible in multiple locations through the web GUI. I used go-drive before this, which had the ability to do that. It's very useful for things like screenshots, where it might fit into multiple folders.

[9001]

Hey, and thanks for trying copyparty :>

Since you're asking, you've probably noticed that copyparty currently prohibits creating multiple volumes which point to the same filesystem location. Unfortunately I don't think that will be healthy to change, but I can think of some other approaches which might be acceptable.

I've started playing with the idea of adding an option (--ln) to link a filesystem path (a folder or a file) into the virtual filesystem so you can specify which URL it'll appear at, and it would inherit the permissions of the parent volume... but I won't promise anything just yet, will have to see what repercussions that might have 😅

Right now, the only approach I can think of is to use symlinks on the OS level. On either linux or macos, you could ln -s /mnt/nas/uploads/screenshots/ /mnt/nas/public/pics/ss which would create a "virtual folder" named ss inside the pics folder, which would have the same contents as the original uploads/screenshots folder. Similarly, you could link just a single file using ln -s /mnt/nas/uploads/test.mkv /mnt/nas/public/ creating a link named test.mkv inside public. The cool part about this approach is that it works with most other software as well, not just copyparty. On the other hand, this does require support for symlinks in the filesystem you want to link from (which is most linux filesystems, but not anything FUSE-based).

You're probably familiar with symlinks already, but I left a full explanation in case somebody else isn't :> And btw, it's possible to create symlinks on windows as well, I'm just iffy on the details.

Not sure when I'll get a chance to take a closer look at the --ln idea, but I'll keep you posted!

[stag-enterprises]

At least for my usecase, I think symlinks will do the trick -- maybe a way to create them from the web interface?

[9001]

Right, so your usecase is a bit more granular, and definitely not the kind of stuff you'd want to be doing in config-files... Still, I may have some good news -- it's complicated :-)

As long as we're talking about single files, then this is currently possible, assuming you first enable file deduplication. If you copy a file and paste it somewhere else, then this creates a symlink to just that file. But, note that if the first file is deleted through the copyparty UI, then the second file will survive with the initial contents.

And, again assuming that dedup is enabled, It is also possible to copy-and-paste an entire folder using the UI -- let's say "dir1" to "dir2". That will create the same folder structure in the new location, which will contain symlinks to all of the files in dir1. But the same thing applies here; if you later add or remove any files inside dir1, then these changes will not apply to dir2.

Right now, there is no way to use the UI to create symlinks if the dedup feature is not enabled. I'm not opposed to adding this if people would find it useful -- it would just be a bit of a headache to work it into the UI in a way that is somewhat intuitive :-)

---

But, when it comes to creating "regular" symlinks, where the new folder is just a living mirror of the original one, then I'm afraid that there is currently no plans to add this... I am worried that this would become a big source of confusion, and could easily cause people to share things they didn't intend to. It has been discussed before in #46 and more recently #115 , but to summarize:

• the biggest issue is copyparty's shadowing feature, where you could have the url /a pointing to /mnt/disk1, but /a/b/c points to /mnt/disk2. In this setup, url /a/b goes to /mnt/disk1/a/b, but url /a/b/c/d goes to /mnt/disk2/d. Now, say that you create a link from /a/b to /a/s, what should happen if you visit /a/s/c/d? Should you see the contents of /mnt/hdd1/a/b/c/d, or /mnt/hdd2/d? And, what if /mnt/disk1/a/b/c has a subfolder named d, which was previously shadowed by the other volume? Should that remain inaccessible or become public? Such questions is why I worry that this will probably be too confusing and dangerous.

  • however, if you create a regular symlink, directly on the server's filesystem using commands like ln -s, then it's more obvious what should happen. It's just that this may not be the behavior you would have expected if you do the same thing in the copyparty UI, since you'll be seeing things from the copyparty VFS point of view.

• assuming the UI lets you create arbitrary live symlinks, it would be very easy to accidentally end up with very complicated setups, which would be difficult to reason about -- another way to accidentally share something you didn't intend to, for example you forget that something secret was linked deep inside some other folder that you later decide to share with somebody else.

Basically I'm actively trying to keep copyparty as close as possible to the server's filesystem -- a quick glance at the volume config and the server filesystem should always tell, without a doubt, what a visitor would be able to access. But I'm also worried that I'd fuck up the code for anything more fancy than this :-P

---

I hope this isn't too much of an inconvenience! Though, if you mention some practical examples, then maybe that can spur some cool ideas for how we could get it to work the way you want :>

[stag-enterprises]

I believe I missed the dedupe feature, that will be very useful, thanks!

Looking at the shadowing feature, I would say that it should probably point to /mnt/disk2/d, but obviously I get that this is a big source for confusion. In #46/1646849264, Gremious mentions “Windows shortcuts”. I think this is a great idea, it would also avoid both previously mentioned issues.

For shadowing, creating a shortcut from /a/s to /a/b, and visiting /a/s/c/d would just redirect you to /a/b/c/d, and regular behavior happens after.

edit: typo