Bug 2757 - option to not follow symlinks or duplicate awareness with symlinks
: option to not follow symlinks or duplicate awareness with symlinks
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 6.2.1
: PC Other
: P4 minor (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-27 05:42 UTC by Mike Benjamin
Modified: 2014-11-29 17:17 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Benjamin 2005-12-27 05:42:46 UTC
Looking through the bug database you may want to join this together with #1372.

Basically there is a symlink to a file that also exists in the music folder, so two copies of it show up in the library.  This is useful for creating file organizational trees rather than playlists and not having to create copies of the files.

To solve my particular issue I've been manually adding a patch to Slim/Utils/Misc.pm by inserting the following on line 607;

                if ( -l $fullpath )
                {
                    next;
                }
                                                                                
My thought was to see if a simple config variable could be wrapped around that.

But I see bug #1372 looks to resolve the final path of the symlink, and then ignore it if it's already known.  This would work equally well to the above *if* symlinks were evaluated last, or gone back through and removed..  It might even work better than the above for people who symlink within the music folder *and* to files outside the music folder.
Comment 1 KDF 2005-12-27 11:40:26 UTC
this should already be fixed.  please try the latest nightly builds).  as a good rule of thumb, nightlies are worth checking before filing a bug report.
Comment 2 Mike Benjamin 2005-12-29 11:35:46 UTC
(In reply to comment #1)
> this should already be fixed.  please try the latest nightly builds).  as a
> good rule of thumb, nightlies are worth checking before filing a bug report.

No, it is not fixed in the nightlies.  I'm seeing duplicates of symlinks and their source files.
Comment 3 Blackketter Dean 2006-04-22 21:44:30 UTC
Dan: are we detecting symlinks?
Comment 4 Dan Sully 2006-04-24 11:37:16 UTC
Mike - does this patch fix the problem for you?

--- Slim/Utils/Misc.pm  (revision 12309)
+++ Slim/Utils/Misc.pm  (local)
@@ -421,6 +421,10 @@
        if (!Slim::Music::Info::isFileURL($fixed)) {
 
                $fixed = canonpath(fixPathCase($fixed));
+
+               if (-l $fixed) {
+                       $fixed = readlink($fixed);
+               }
        }
Comment 5 Dan Sully 2006-06-07 11:30:49 UTC
Mike - does the patch work for you?

Thanks
Comment 6 Blackketter Dean 2006-06-20 11:26:43 UTC
Mike, is this patch good for you?
Comment 7 Dan Sully 2006-06-21 13:09:00 UTC
Fixed in change 8079
Comment 8 Chris Owens 2006-06-27 14:22:05 UTC
This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.
Comment 9 Richard Hazlewood 2014-11-29 17:17:48 UTC
Many years later...

I've been seeing this issue with all of the latest released versions (7.x).  Currently using 7.7.5.

Not sure if it's some edge case with my set up:

Hardware: Sheevaplug
Software: Debian package 7.7.5.
Music catalogue stored on external USB drive, connected to Sheevaplug.
External USB drive is formatted as NTFS; mounted using ntfs-3g.

Example of directory structure:

Music
 |
 +--Artist1
 |  |
 |  +--Album1
 |     |
 |     Track1
 |     ...
 |
 ...
 |
 +--<symlink to Artist1>

The tracks are appearing twice in the media server under this set up.

A (bash) console on my Sheevaplug quite happily creates (and reports) the symlinks on the NTFS drive, but I wonder if the resolution to canonical path does not work?