[Nepomuk] Issues with non persistent filesystems/mounts and Nepomuk

[Sebastian Trüg]

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
filex:// URLs
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
mount.
Any ideas?

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:/"
issue. :)

Cheers,
Sebastian

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
> issue.
> 
> 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.
> 
> 
> Daniel
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>