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 > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
