How symbolic links are handled in library/shared files

[slrslr]

Hello in Options/Muwire/File sharing i see no option to control how Linux symbolic links (or Windows .lnk ?) are handled.

I see that on my Library tab the folder that contains sym. links does not display these in Muwire, on Library view. I would prefer to see these.

Also when someone is browsing my library, the sym. links are there for the purpose to group related files in the folder even real destination file is somewhere else.

If some user decide to download multiple files from me one is sym. link and other is real file sym. link is linking to, muwire would not download 2 times. I am just saying, not sure how/if muwire works this way.

So my feature idea for considering it to:

• display sym. links as files in folders (now not displaying)
• do not follow (display) sym. link folders and its contents, but user can enable it in muwire settings?

[zlatinb]

Right now for simplicity MuWire resolves all symlinks or windows shortcuts and only shares the target file. There have been requests to change that behavior, and I think it should change, but it would be a major change and it needs to be analyzed carefully.

To add an option whether to follow symlinks is easy, but the user would have to re-index their library every time they change that setting. So for backwards-compatibility the default setting would be to follow symlinks.

Regarding downloading, the download request is done by file hash, so the user would not download the same file more than once.

[zlatinb]

There are two general ways of handling this that I can think of at the moment:

A) Just stop resolving symlinks, no other changes.
Pros:

• Simple to code
• Existing libraries will continue to work because they are already resolved/canonicalized

Cons:

• When sharing more than one symlink to the same file, the same file will be hashed more than once. Same goes for directories.

B) Make MuWire aware that the files are symlinks.
Pros:

• No hashing more than once
• The library will reflect the filesystem more accurately

Cons:

• Requires changes to the fundamental file storage to identify which shared file is a symlink
• Un-sharing is not trivial - what if the target file gets unshared, do the symlinks get unshared too?
• What if there are a loops or folders containing links to parent folders?

[zlatinb]

@slrslr I think I have option B working in git. Can you please check out the latest code and test?

• Files are hashed only once; linking to files already hashed does not cause a re-hash
• Creating and removing symlinks to folders inside other shared folders is handled correctly

@someguy2013 please take a look at this too, if you can't build from git I can prepare a .zip distribution with just these changes.

[someguy2013]

I'm sorry that I haven't been able to test this. I just wanted to reply so you knew your work/prioritization of this is appreciated.

I look forward to being able to have one "share" directory, and create sym links there for everything I'm sharing. (I can keep the commands in a script/text file to repopulate the share directory when necessary.). To me, that's simpler than sharing across my hard disk. The "library" tab will match my shared directory(?). Plus, it alleviates MuWire of knowing anything more than my share directory(?). I think that would be a positive and security-minded (if you don't know more (paths) than you have to, that's better?).

For that reason, I think I would vote for option A (don't resolve links). Regarding the "con," I think if someone symlinks to the same file (or dir) more than once, then it deserves its own hash. I can't see how people would do that without it being intentional. In which case, it is unique within the shared structure? (I think the benefit of doing it this way is that MuWire doesn't have to know more than it needs to know.).

I'm sorry I haven't been able to test. I like what you're doing with MuWire. I think it's great.

[zlatinb]

Hi, no worries, if you need a bundle to test and don't mind telling me which operating system I can prepare one for you. Otherwise just grab the .zip from the comment below.

Regarding options A vs B, I've already coded the harder option B. MuWire should behave the way you describe with your directory structure.

[zlatinb]

@Searinox here is a build with the latest code: https://muwire.com/downloads/MuWire-0.8.10-GitHub102.zip

[slrslr]

I am unsure how to test this properly. I can think of only following:

Filter my library and global search for the file that i know is symlink, yes, in both cases it displays correctly the file in the folder even the file is symlink. Previous build do not displayed the file when it was the symlink 👍

Then i have searched for the folder that i know is symlink within my shared directories. This folder/directory links outside of shared directories by the way. Yes, it shown the folder and its contents (2 times) which seems good, except i see following possible issue with this behavior:

for example in the past/future i link/ed (without thinking about muwire) from non-sensitive folder(willing to share) to the related folder in different location that contains sensitive data. That is why i have mentioned for consideration not to follow directory symlinks by default, only for example if user explicitly enable Muwire option like: "Follow directory symbolic links pointing outside of the shared directories (risk of accidentally sharing sensitive data)"

If you have more ideas how to test, let me know. Thank you

[zlatinb]

Thanks for testing. Regarding what else to test - creating new symlinks, deleting symlinks, unsharing then re-sharing symlinked files or folders, just every day usage will help.

Regarding a config option about following symlinks outside of the shared folders hierarchy - if I were to add such option I would make it enabled by default. The big problem with it is that if the user changes the option they will need to re-index their entire library. I don't think the current behavior increases the risk of accidental sharing, that risk is always there and it's the user's responsibility to check what is being shared in the Library tab.

[slrslr]

creating new symlinks, deleting symlinks, unsharing then re-sharing symlinked files or folders

i have finished testing these and seen no issue except the last thing: un-sharing and then sharing again the symbolic linked directory. Adding it again for sharing caused, numerous pop-up windows. I have copied error here

On second attempt, adding that sym. linked folder for sharing caused no error to appear.

Un-sharing & sharing sym. link FILE caused no issue (it was file from different directory)