Add symbolic link support

[MikaelFangel]

Describe the bug

When clicking on a symlink, it doesn't follow the symlink, but rather it opens it in the default file explorer on the system.

Reproduction

1. Create a symlink
2. Open spacedrive and double click on the symlink
3. Wait for the file explorer to open in a new window

Expected behavior

That the symlink opens within spacedrive

Platform and versions

- system: `"x86_64-linux"`
 - host os: `Linux 6.1.56, NixOS, 23.11 (Tapir), 23.11.20231009.f99e5f0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.17.0`
 - channels(root): `"home-manager-23.05.tar.gz"`
 - channels(mikael): `""`
 - nixpkgs: `/nix/store/902j4afzd3glcviwv1kzkqq3bb05y736-source`

Stack trace

No response

Additional context

The application is run using the app image and using this build file on NixOS: https://github.com/MikaelFangel/NUR/blob/master/pkgs/sp/spacedrive/default.nix

[PanoptesDreams]

This problem is also in Windows. I use 'A:' as a junction, junction.

Each junction folder appears as a black tile and when clicked on, it opens the path in the native file explorer.

[brxken128]

Is this on an indexed location, or local/ephemeral?

[PanoptesDreams]

For me it is local. I quickly created and tested on another system and it's the same behavior.

[brxken128]

Hmm, I think the best solution here would be to follow symlinks within the ephemeral/local browser, but I'm not too sure how to handle it in a multi-node setting (e.g. you have a location from another node synced, and that contains a symlink, you wouldn't be able to open view it as it's not local to your current device/node).

@fogodev What do you think?

We could arguably do with an upwards-curved arrow icon to imply a "jump", I think that'd suit symlinks pretty nicely.

[fogodev]

For ephemeral locations, following symlinks is pretty fine. They're local only always, so I don't think it will be a problem with multi node setups. We just need to check in the non_indexed_location::walk if the file is a symlink and if the symlink is to a directory. Marking the file as a directory accordingly.

For indexed locations it will be another different beast to slay. Last year when I created the walk function for the indexer I explicitly avoided symlinks as they could lead to cycles and left a to-do comment to solve it later, but never got the time to revisit this part again.

[fogodev]

The relevant parts are here https://github.com/spacedriveapp/spacedrive/blob/main/core/src/location/non_indexed.rs#L141-L146 where we check if the file is a directory and add in the directories vec to be solved later. Just need to check in the else if the file is a symlink to a directory and push it to the directories vec and continue.

And here https://github.com/spacedriveapp/spacedrive/blob/main/core/src/location/non_indexed.rs#L231-L254

I'm not near a PC until tomorrow (and my backlog for the week is pretty full nonetheless LMAO) so feel free to open a PR, otherwise I will fix it ASAP.

[fogodev]

Although another way to handle it would be to have a new kind of symlink files in the frontend, then check if they're directory or not. This would enable to have different icons.

[allisoneer]

I took a look at this because of the good first issue tag.

One issue is that symlinks can also be files(not just directories) and in that scenario the current spacedrive frontend displays the size of the symlink file and not the size of the source. I checked my local file manager and see that a distinct symlink icon is displayed on both directories and files, files sizes are displayed as their source sizes(and types) instead of the link size(and unknown type), and both directories/files display what path they are linked to.

I think mimicking that logic and display decisions(or similar) in spacedrive will be important to avoid user errors and ensure a good experience, and that that approach will require handling changes on the frontend as you mentioned.

Note: it may be fine to still do a quick check in core to see if the link is a directory or not to keep the code in non_indexed_location::walk uniform, but that the complete solution requires display changes.

[PanoptesDreams]

Or maybe a chain link like Win Explorer?

I've never seen a chain icon in Windows (10) to represent a SYMLINK.

In Windows 10 the standard .lnk/shortcut overlay icon is just the generic arrow.

[PanoptesDreams]

A .lnk is not a Symlink or NTFS junction. (It's possible that the chain symbol is added by Link Shell Extension (LSE) though, it's among the standard things I immediately add to a new windows install)

-_- I know what a junction is, maybe you should read the above comments and validate your info before trying to educate me.

In Windows, Junctions use the standard .lnk icon.