In Nepomuk, we always store the full url of the file. While this makes our lives easier in certain cases, it also makes handling stuff like system links really hard. This page documents how we deal with system links.

We always try to store the full qualified name of the URL. That means that given the following directory structure

DirA/FolderA <br\> DirA/LinkA ---> DirB <br\> DirB/FolderB <br\> DirB/FolderB/FileC <br\>

We would save save the URL of DirA/LinkA/FolderB/FileC as DirB/FolderB/FileC.

File Watcher

We should not be installing watches twice. How do we go about doing this? There are a lot of edge cases.

Some of the crazy cases from the top of my head -

1. /media/disk/systemLink -> /home/vishesh/Music/SomeFolder/. When one unmounts /media/disk, one shouldn't remove the watches for /home/vishesh/Music/SomeFolder.

File Indexer

When saving the URL of the file, we save the canoncialFilePath. However, when testing if the file should be saved one probably should test its relative URL.

How does one avoid cycles in BasicIndexingQueue?

Index Cleaner

If we only save the canonical file path, then the index cleaner will clear out the metadata of those resources when it is run. How do we counter that? We will need some way to map the canonical file URL to its many possible relative URLs and check if those files should have been indexed before remove the metadata. This cannot be done in a query. It will have to be done manually. That will result in large amount of CPU consumption in the cases when the number of files in the system linked directory are very large. Eg - The user has a system link to /media/LargeMusicDatabase in their /home/ directory.

Resource

We need to be able to initialize a resource with all possible combinations of file URLs. How does one go about doing this?

When given Resource("DirA/LinkA/FolderB/FileC") we would need to translate it to DirB/FolderB/FileC. This can easily be done using QFileInfo::canonicalFilePath(). How would we do the inverse? Also there might be many URLs whose canonical file path is DirB/FolderB/FileC. We don't really need to ever do the inverse. Do we?

ResourceManager cache

The ResourceManager has a cache which maps the nie:url to the resource URI. Should we be storing the system link URLs in this cache? It doesn't seem like a good idea, cause then we will have to keep the cache up to date, which is quite hard.

Alternative Solution

One really neat solution would be to not store the nie:url at all, and only rely on nfo:fileName and nie:isPartOf. That way system link handling might be easier. Might.

That will however only happen with KDE 4.11. It's too big of a change to introduce in KDE 4.10.