[Nepomuk] Issues with non persistent filesystems/mounts and Nepomuk
trueg at kde.org
Tue Jun 15 11:50:48 CEST 2010
I suppose a solution would be to remember the mount and check if it is
mounted before removing metadata or returning results.
Thus, we would handle two situations:
1. removable media like usb keys and the like which will result in
2. "persistent" mounts or whatever you want to call it, i.e. those that
are always mounted at the same path and thus, do not need filex:/ handling.
The question is: how to decide if it is a "persistent" or a removable
BTW: there is no "nepomuk:/ vs. filex:/" issue since the latter is used
as nie:url values, meaning if anything there is a "file:/ vs. filex:/"
On 06/04/2010 12:29 PM, Daniel Winter wrote:
> Nepomuk is not able at all to work with NFS/CIFS (Samba) and other
> mount types which are not always mounted.
> I recently bought a NAS to use it on different computers/laptops. And
> I believe I am by far not the only one with that or other setups using
> NFS/CIFS (and others).
> Sure it indexes nfs mounts without any problems. But as soon as I am
> not at home with that laptop or for other reasons having not mounted
> that filesystem it deletes everything again. Makes it kinda useless.
> Because the huge amount of data there it would be really usefulll to
> have that i the index.
> Nepomuk generaly handles non persistent filesystems when they are
> reported by solid. (Though I believe that the transition from
> nepomuk:// to filex:// uris will take forever when you use a big
> external hdds (there are 2 TB devices these days) with lots of files.
> Solid is about hardware an NFS or bind mount is not hardware, so I am
> not sure if adding that to solid is the correct way to solve the
> On a side note: There is also a general KDE issue with that. GTK/Gnome
> file open/save dialogs also show NFS or other mounts in the "Places"
> like view. KDE's equivalent only shows Solid FSs.
> I am not sure what would be the best way to solve the issue.
> I believe the nepomuk:// vs. filex:// concept (different handling
> for file resources on local storage and removable storage and even
> worse different handling for removable storage which is not there at
> the moment) brings a lot of complexity on a lot of places: meta data
> moving, export handling, creating of custom queries, find the right
> resources. And for big storage devices I believe it takes hours on
> unmounting to move nepomuk:// uris to filex uris.
> Another problem with that is: Programs making references to those
> nepomuk:// uris which they are from the beginning (like in the
> recently used files, or in playlists or in .desktop shortcuts) ,
> those will broke upong transition to filex.
> (Or Do I have a complete wrong understanding of how that filex:// vs.
> nepomuk:// thing works?)
> I do not propose a solution or anything, because I do not really
> understand the reasons for and how the current systems works.
> Nepomuk mailing list
> Nepomuk at kde.org
More information about the Nepomuk