I don't think this is possible in Amarok anyway, moving to wishlist.

I'm surprised to hear that.  On a unix platform, the client software has to take special action to see the symlink instead of the contents of the file.  I dug in a bit.

In CollectionScanner::readDir(), this seems to be the line killing me:

 384         const QFileInfo &f = fi.isSymLink() ? QFileInfo( fi.symLinkTarget() ) : fi;

I found some old discussions about being careful about multiple symlinks pointing to the same file, but could there not be a config option in amarok (and corresponding flag in amarokcollectionscanner) to determine if this line should be run for those that know their symlinks only point to a single file, or prefer proper symlink semantics?  I'm pretty sure this would solve my problem, but I don't have a dev environment setup to test it at the moment.  Am I missing something?

I'm surprised to see this marked as wishlist, as this particular bug makes amarok unusable for me (my collection has zero items).  The old discussions seem to indicate amarok 1.x had this ability.

Well, Amarok 2.x is a complete rewrite, so new function not yet implemented belong to the wishlist. I notified the developer.

Hi,
The collection scanner does follow symlinks.
We have had a problem with that just yesterday where a user placed a symlink to a very slow NTFS partition inside his collection.

However I did not verify that links to files work. I will do that right now.

Just checked it.
It's working all right with the 2.4 beta.

Links to read-only audio file. No problem.

Closing as fixed in the upcoming Amarok 2.4, to be released later this month.

Hello,

It seems to me that this problem was solved in v2.3.2 but was reintroduced in v2.4.0:

/tmp/amarok% git checkout v2.3.1
Previous HEAD position was a38b0e5... bump plugin-version for 2.3.2
HEAD is now at 25111af... bump plugin version for release
/tmp/amarok% grep -R isSymLink *           
utilities/collectionscanner/CollectionScanner.cpp:        const QFileInfo &f = fi.isSymLink() ? QFileInfo( fi.symLinkTarget() ) : fi;
/tmp/amarok% git checkout v2.3.2 
Previous HEAD position was 25111af... bump plugin version for release
HEAD is now at a38b0e5... bump plugin-version for 2.3.2
/tmp/amarok% grep -R isSymLink * 
utilities/collectionscanner/CollectionScanner.cpp:        if( !fi.exists() || ( fi.isSymLink() && !QFileInfo( fi.symLinkTarget() ).exists() ) )
/tmp/amarok% git checkout v2.4.0 
Previous HEAD position was a38b0e5... bump plugin-version for 2.3.2
HEAD is now at b52a7b6... bump plugin version for 2.4.0
/tmp/amarok% grep -R isSymLink * 
utilities/collectionscanner/Directory.cpp:        const QFileInfo &f = fi.isSymLink() ? QFileInfo( fi.symLinkTarget() ) : fi;
utilities/collectionscanner/CollectionScanner.cpp:        const QFileInfo &f = fi.isSymLink() ? QFileInfo( fi.symLinkTarget() ) : fi;


Thanks,

Dimitri

Dimitri,
I checked this problem with 2.4 and haven't changed anything substential since.

I also don't see what a grep over the different Amarok versions should prove.
Can you please execute the amarok_collectionscanner for such a directory and tell me if it finds the files.

Also, since you seem to be proficient with git, you could try out the git version and report if the error still occures.

Created attachment 58121 [details]
Symlink Collection Scanner Test

Hello,

Ok I have done test with version 2.3.1 2.3.2 2.4.0 and 2.4-GIT. First I setup a directory with 2 mp3 file, 1 on the root path and the other on a subdirectory. Then I do a amarokcollectionscanner -r for each version (2.3.1 2.3.2 2.4.0 and 2.4-GIT) and everything works well. After that, I setup git annex, so the mp3 file are only symlinks. And I launch another amarokcollectionscanner. The result seems to be good only with the 2.3.2 version. 

That's why I was doing grep on my previous comment.

The results of my test are in attachment.

Thanks for your help,

Dimitri

Created attachment 58207 [details]
Patch that seems to correct the symlink problem

Hello,

As I really wanted to use the symlink of git-annex, I searched a little and I found this commit of Jeff Mitchell (at the bottom) had resolved this problem the first time. As this modification was squashed, I try to backport this in the 2.4.0 version and it seems to works succesfully for me. The patch is in attachment.

As I'm not a developper and even less a c++ developper, you should be carefully about those modification ;).

Thank you,

Dimitri

commit 30c85f027557318d1c64b6b19c46903f62eaa4e4
Author: Jeff Mitchell <mitchell@kde.org>
Date:   Fri Aug 27 16:51:28 2010 -0400

    Resolving directories' symlinks during scanning meant that directories could be seen as "out of the collection" and show up during full scans but disappear during incremental scans.

    Thanks to tampakrap (Theo Chatzimichos) for helping track this down.

diff --git a/utilities/collectionscanner/CollectionScanner.cpp b/utilities/collectionscanner/CollectionScanner.cpp
index f0cef67..cbe55a1 100644
--- a/utilities/collectionscanner/CollectionScanner.cpp
+++ b/utilities/collectionscanner/CollectionScanner.cpp
@@ -379,12 +379,10 @@ CollectionScanner::readDir( const QString& dir, QStringList& entries )
     QStringList recurseDirs;
     foreach( const QFileInfo &fi, list )
     {
-        if( !fi.exists() )
+        if( !fi.exists() || ( fi.isSymLink() && !QFileInfo( fi.symLinkTarget() ).exists() ) )
             break;
 
-        const QFileInfo &f = fi.isSymLink() ? QFileInfo( fi.symLinkTarget() ) : fi;
-
-        if( f.isDir() && m_recursively && !m_scannedFolders.contains( f.canonicalFilePath() ) )
+        if( fi.isDir() && m_recursively && !m_scannedFolders.contains( fi.absoluteFilePath() ) )
         {
             //The following D-Bus call is used to see if a found folder is new or not
             //During an incremental scan the scanning isn't really recursive, as all folders
@@ -395,16 +393,16 @@ CollectionScanner::readDir( const QString& dir, QStringList& entries )
             bool isInCollection = false;
             if( m_incremental && m_amarokCollectionInterface )
             {
-                QDBusReply<bool> reply = m_amarokCollectionInterface->call( "isDirInCollection", f.canonicalFilePath() );
+                QDBusReply<bool> reply = m_amarokCollectionInterface->call( "isDirInCollection", fi.absoluteFilePath() );
                 if( reply.isValid() )
                     isInCollection = reply.value();
             }
 
             if( !m_incremental || !isInCollection )
-                recurseDirs << QString( f.absoluteFilePath() + '/' );
+                recurseDirs << QString( fi.absoluteFilePath() + '/' );
         }
-        else if( f.isFile() )
-            entries.append( f.absoluteFilePath() );
+        else if( fi.isFile() )
+            entries.append( fi.absoluteFilePath() );
     }
     foreach( const QString &dir, recurseDirs )
         readDir( dir, entries );

I have the same problem as dim.kde also using git annex. Could using symlinks in the collection be added as an option?

I did checked it now with different settings - one has to include the ./.git/annex dir with the 'real' files in the collection and then it is working!

It is working due to the fact, that the annexed files are included in the collection and sorted due to the included tags. The links are not used at all. This helps as long as all files have tags ... For some files without tags an option to follow symlinks would be helpful. But, the current situation is working OK.