Until now symbolic links were not handled in Nepomuk. Today I commited the last patch for the new symlink support in Nepomuk. The solution I chose is not the theoretically perfect one. That would have taken way to much effort while introducing all kinds of possible bugs, regressions, API incompatibilities, and so on. But the solution is nice and clean and simple.
Essentially each direct symlink is indexed as a separate file using the content of its target file. (This is necessary since a direct symlink might have a different file name than the target file.) The interesting part are the indirect symlinks. Indirect symlinks are files in a folder which is a symlink to another folder. An example:
/home/trueg/ |-- subdir/ |-- thefile.txt |-- link/ -> subdir/ |-- thefile.txt
Here I have a folder “subdir” which contains a file “thefile.txt”. The folder “link” is a direct symlink to “subdir” whereas “link/thefile.txt” is an indirect symlink to “subdir/thefile.txt”.
Indirect symlinks are simply stored as alternative URLs on the target file resources using the kext:altUrl property. (The property is not defined in NIE since it is not theoretically sound with respect to the design of NIE. It needs to be considered a beautiful hack.)
The only situation in which the alternative URLs are actually needed is when searching in a specific folder. Imagine searching in “/home/trueg/link” only. Since there are no nie:url values which match that prefix we need to search the kext:altUrls, too.
The result of all this is that nearly no additional space is required except for the kext:altUrl properties, files are not indexed more than once, and files in symlinked folders are found in addition to “normal” files.
In my tests everything seems to work nicely but I urge you to test the nepomuk/symlinkHandling branches in kdelibs and kde-runtime and report any problems back to me. The more testing I get the quicker I can merge both into KDE 4.8.
Lastly the pledgie campaign is done but the search for funds goes on:
Trueg's Blog 
Hi there,
Very nice work. What happen with broken symlinks? Are they stored or just completely discarded? And with a symlink to another symlink? How that work?
I have another question but not related to symlinks. Does Nepomuk::Query::Query() support case insensitive queries on metadata?
plasma-mobile/components/metadatamodel/metadatamodel.cpp uses Nepomuk for searching files and I would like to make case insenstivive queries. The documentation (http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/QueryService) does not explain how to do that. Is it possible?
The “order by” clause is case-sensitive in sparql:
http://www.entagen.com/blog_files/6e69c54a361952e9ea5b341e156e7161-5.html
That clause is used by plasma-mobile/components/metadatamodel/metadatamodel.cpp when building the nepomuk query.
Can you confirm that? Do you think it is possible to use the xpath-functions mentioned in the link above in kdelibs/nepomuk/query/querybuilderdata_p.h?
Is it possible to test in a KDE 4.7.4? If possible I try to do some tests this weekend.
Should “link/ -> subdir1/” instead be “link/ -> subdir/”? Otherwise I’m confused…
Also, what is the perfect solution that is hard to implement? Would that also be storing direct symlinks as alternate URLs for the original file, like indirect symlinks? That seems like the most elegant solution to me, but I can’t figure out why it would take so much more effort.
what happens when I delete a symlink to a dir containing lots of files? does neponuk remove all those altUrls too?
I am working on that ATM actually. It works but I need to write more unit tests and optimize a bit.
In an offtopic rant, can you fix Akonadi Nepomuk feeder just like you’ve fixed the File Indexer and Nepomuk in general? Even when I disabled mail indexing ─a troublesome feature─ I’m still seeting 100% CPU spikes.
Pingback: Is KDE 4.8 ready now? - Page 7