"Make symlink" button alongside the cut/paste ones

[Gremious]

Hello!
I think it would be nice if right next to the cut/paste buttons when you select a file, there was also a "link" button. Very useful when running with no-dedup and wanting to selectively ""copy"" some files, esp. when sharing across volumes.

(And since windows is bad at symlinks I guess just don't show it unless you're admin/have hardlinks enabled on windo.)

[Gremious]

Some notes for the future - I wanted this cause:

1. I have an images folder and I want to link a file and rename it to folder.jpg without actually going to my servers filesystem.
2. I wanted to share some pictures to another volume without moving or duplicating them, e.g. to make a small 'more-public' photo album.

Another note though, and idk if this should be a separate issue, while using copyparty more I noticed myself wanting to make symlinks (or some other type of shortcut e.g. like windows shortcuts) of directories, in order to make a little favorites/ folder.

In my mind, if you click a linked shortcut it just jumps to that actual location rather than infinite nesting or anything. Otherwise cross volume symlinked directories with varying permissions sounds very annoying.

But I just now realized as I'm typing this, you can just put a <a href="very/nested/sub/directory/">favorite folder</a> in a README.md, so this is actually very low prio or straight up ignorable request. I don't really know if there's another usecase for directory shortcuts outside of "I guess this is always available on the tree sidebar".

[9001]

Thanks for the followup :> And very useful hearing the usecase you had in mind, selecting a specific picture as the folder's thumbnail like that.

I haven't forgotten about this, it's just a bit tricky! I don't feel too confident about adding support for symlinking entire folders -- one thing I can think of is how it would interfere with shadowing (hiding the contents of a subfolder by mounting another volume over it), but there's probably more interesting consequences too...

So I was thinking of adding support for recursive-copying of files/folders, kind of like how you can move files right now, except it won't delete the original files afterwards. This would trigger all the usual deduplication logic, so when you use the web-UI to copy a file, then usually it would just symlink/hardlink it instead, all according to the volume config. However, this has the drawback of being a point-in-time copy, so if you add more files to the original folder, then they won't automatically appear in the copy.

And I'm also not sure how to do the UI -- I guess there would have to be a way to rename files during the copying, especially for the usecase you mentioned where you'd copy-paste a file within one folder, just with a new name. Currently, if you try to move a bunch of files to another place, and there happens to be a filename collision (between any of the selected files) then it'll just abort, so that's no good. Maybe something similar to the batch-rename UI, or perhaps just a separate yes/no/rename-dialog for each conflict (but those are so clunky and inconvenient to use...)

Maybe it's a good thing I'll be AFK for the next few weeks, gives some time to think about it :p

Right now I guess there's the inconvenient workaround of downloading the picture you want as the folder's thumbnail, renaming it to folder.jpg and then uploading it back to the folder -- assuming you haven't disabled deduplication, then that would get symlinked nicely :>

And with the xlink volflag you could always download and reupload files to another (more public) volume without spending any additional space, as it would deduplicate and symlink across to the other volume -- although I'll admit this is one of the lesser-well-tested features, so let me know if you give that a go and anything somehow misbehaves!

[Gremious]

one thing I can think of is how it would interfere with shadowing

This is very true. Honestly something like symlinked/hardlinked directories is probably a massive danger zone for a whole lot of reasons.

Thinking about it, here's an idea: only for directories, you could probably totally do client-side links. To show an example:

"cool folder" does not exist on disk, it is only noted internally in a file/db as e.g. a to -> [from] map or something. Then when you draw the page you look at the map and render "fake folder" link buttons. The button is nothing more than a <a href="very/nested/sub/directory/cool folder"></a>. If very/nested/sub/directory/cool folder moves, you go over the map and update all the entries. You can rename the button, it does not affect the real folder, just changed the map entry.

Permissions work as expected since you're just going to a url, I don't think they have to care about shadowing e.g. you could have a folder foo and create a link named foo in the same location, it doesn't really conflict or anything. They should just be a client-side button, entirely ignored by the rest of copyparty.

e.g. reinvent Windows shortcuts lol

I guess there's nothing stopping you from also doing point-in-time copies on top of that, if you actually wanted to legitimately copy a folder? Then, for directories, you have cut, copy and link all three - the holy trifecta.

---

re: Renaming - There's always the good ol' funny image (1).jpg. The simplest flow is you copy 1 or many files, it just does it and appends (n) at the end of any dupe-names, and then you select an individual file to rename as you normally would. I myself personally would not necessarily mind at least that. Though as you said, perhaps one could think of a cool rename dialogue or something.

---

And yeah, for now I rely on re-uploads with regular deduplication!

Enjoy your ?break c:

[9001]

Okay, so this kind-of, sort-of got implemented in #115 -- it will create a symlink if you have dedup enabled, and a full copy otherwise. There's a beta over there for now, but as usual the release isn't too far off -- maybe a week or two.

Let me know if it doesn't cover your usecase :>