Symbolic link handling in paths is inconsistent.

[Ferroin]

Before posting

Please follow the steps below and check the boxes with [x] once you did the step.

• I checked the issue tracker for similar issues
• I checked the changelog if the issue is already resolved
• I tried the latest Clementine build from here Tested a local build from the upstream git tree, built on and for 64-bit Linux

System information

Please provide information about your system and the version of Clementine used.

• Operating System: Any Linux system, possibly also on OS X
• Clementine version: At least 1.2.3 and newer, possibly earlier versions.

Expected behaviour / actual behaviour

Currently, Clementine is inconsistent in it's handling of symbolic links in paths. When adding a path to the Library, Clementine will canonicalize the path (it's internally doing the equivalent of realpath), thus eliminating all symbolic links in it. However, when adding songs to a playlist from the file tab, or by using the command line, or by drag-and-drop from another application, it does not resolve symbolic links. The inconsistency can cause significant confusion, as well as undesirable side effects (see #5351 for example).

At an absolute minimum, this handling needs to be made consistent (which would avoid things like #5351).

ideally, we shouldn't be canonicalizing the paths that are added to the Library, as this breaks one of the more common use-cases for symbolic links (redirecting things such that you can trivially change the redirection in one place, instead of having to go through numerous applications to do so), and we should just be trusting the VFS layer to resolve things for us properly.

[logological]

I think this is a duplicate of Issue #2299 (going back to Clementine 1.0.1).

[chrisgraham]

Same issue applies to imported .m3u files. Even though an .m3u is referencing something in the library, using a relative path, it imports as a new file using an absolute path (realpath). This means ratings do not show and can not be set.

[chrisgraham]

I should also note that if you try and workaround the issue adding the realpath roots to the library in Preferences, you'll just end up with duplication. This should not happen either.

[chrisgraham]

A working workaround is to use bind filesystem instead of symlinks.

[braoult]

A working workaround is to use bind filesystem instead of symlinks.

Except that everybody can make a symbolic link, not a mount. And when source dir is a network automount, a bind is not desirable, preventing automount to do its job (I think).

[smithjd15]

ideally, we shouldn't be canonicalizing the paths that are added to the Library, as this breaks one of the more common use-cases for symbolic links (redirecting things such that you can trivially change the redirection in one place, instead of having to go through numerous applications to do so), and we should just be trusting the VFS layer to resolve things for us properly.

Agreed. The library realpath part of this makes playlist creation for consumption in other players more difficult than it should be.

Edit: Pull request (patch avoiding canonical path resolving for added library paths) #6919