On 06/15/2010 01:54 PM, Daniel Winter wrote: > 2010/6/15 Sebastian Trüg <[email protected]>: >> Well, maybe the simplest solution would be to ask the user on unmount. >> Let them decide if we want to keep the data, make it portable, or remove >> it.... > > Could work, if the unmount happens when a user is using the system. I > mean an unmount could happen at logout or shutdown. A view for every > filesystem in the Nepomuk KCM would help. One could there delete all > resources on it (for example if a lost the usb hdd), enable exporting > of data and so one.
That is a nice idea, yes. > On the technical side, what would be the difference betwen a portable > and not portable filesystem? Only the portable resources would have a > link to the filesystem they are on? Portable resources would have filex:/ nie:urls. > Another question: > > Could an application link to a filex: or nepomuk: url for example in > recently used files or in a playlist? I mean sure it could, but > nepomuk:/ uris will become filex uris sometime in the future, right? nepomuk:/ URIs never change. That is the whole idea. > Consider this: > > I mount a big usb hdd and select it's path or some of them for > indexing in Nepomuk. > > Nepomuk will index them using nepomuk:// urls. And nie:url pointing > the real path on filesystem level. That correct? yes > Then on unmount Nepomuk detects the unmount and has to rewrite every > nepomuk: uri to a filex:/ uri? no. Like I said: the nie:urls are rewritten. The resources are untouched. > Or still wrong? Does it already use filex: on first index? Also what > about things like rating a file on such da filesystem (when indexed or > not indexed) Ratings are handled in the exact same way. Nepomuk::Resource matches local file paths to existing filex:/ nie:urls. The system works very well. Its only problem is the performance with many files. Cheers, Sebastian _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
