I’m always losing files in my immense collection of accumulated documents and structures of folders, which have for a long time become slightly less than contextual. Lurking in many depths of paths structured as per; /home/karl/Miscellaneous/Misc/Other/Stuff/Old Stuff/Things from before/A long time ago/ are useful files I barely remember creating.
VFolders - Links to video
With tracker, and fster we’re edging toward a solution to making everything accessible without the pain of sorting. Using these tools we can build semantic fuse file system. Still in it’s early stages and with lots of features to come, take some time to try it out!
Installing Tracker+Fster VFolders
Install Tracker 0.7.24, for ubuntu users there’s a nice PPA available;
sudo add-apt-repository ppa:tracker-team/tracker-unstable
If you’re using another distribution you can follow the build instructions found here.
If you’re using ubuntu you can install the fster deb file straight from their website.
If you’re using another distribution, or are on amd64 like me you’ll need to build fster, in order to do this you’ll need the following packages;
- cmake >= 2.8.0
- fuse >= 2.8.1 (2.7.4 seems OK)
- tracker-client >= 0.7.24
- libxml2 >= 2.7.4
- libattr1-dev
Then follow the build and install instructions as per the fster website; You may need to make /etc/fuse.conf readable by all after install as it seems to be created with 640 permissions.
Using Tracker+Fster VFolders
You need to make sure that tracker has started indexing everything, generally running tracker-control -s will get that off the ground, you can also re-log-in in order to start tracker with the GNOME session.
Start up fster by running fster /path/to/virtual/Virtual/ -d -c /path/to/fster_media_library.xml, ../conf/fster_media_library.xml from your build folder if you built it yourself, not sure where this file is in the deb, please someone let me know if they use it on i386 
Now you can browse all of your videos, pictures and music via the semantic data store. Obviously this is just a starting block, and much work needs to be done in the future, for instance figuring out which folders to auto-generate within each folder based on the common relationships of the items, creating folders resulting in sub-queries and features of that nature to be added.
Even now I see a lot of potential in taking this route forward to improving the usability of the file system and nautilus.
GNOME3 and the future of the file system
Nautilus is, as has been previously mentioned due an overhaul. In order to allow Tracker+Fster to exist on GNOME nicely, and be used in Nautilus I propose we focus on improving how devices appear in nautilus, and allowing devices to specify their position, and function in the sidebar, as well as using configurable icons, emblems, backgrounds and other existing features to improve their functionality.
We should consider making the default bookmarks and the appearance of devices and bookmarks more configurable for folders and devices. For instance certain fuse devices might want to appear as default bookmarks as in replacing the home folder with vfolders, these devices or folders could also specify whether or not they wish to display the mount/unmount button. The separators, the positioning, grouping and spacing of the places are all artificially imposed at present. If concentrate on improving these things we can introduce fuse filesystems as first class citizens in nautilus.
By concentrating on the fuse/device integration with nautilus rather than a specific filesystem add-on inside the nautilus UI we keep nautilus small and unbundled from the data store and allow for other fuse filesystems like GNOME Activity Journal with Fuse to benefit from the same improvements.
I also think we need to do more in order to detect types of devices and include more device icons, e.g. iPods, Phones, Cameras, Memory cards, and other attached storage devices can have device icons and it would be great if we could try and utilise any and all available icons appropriately, like the icons available in places like Quantum Bits. Using icons and branding, watermarked backgrounds and emblems in nautilus along side the device, bookmark or folder improves the connection between what the words represent and the function of the item. Dropbox is very good at integrating into Nautilus using emblems, and there’s no reason that other folders and fuse file systems can’t achieve the same level of usability with features already present in Nautilus.
Tags: GNOME
Fuse is very linux specific – it might therefore make more sense to use GIO/GVFS backend instead of Fuse to deliver this functionality so it can be used in nautilus on all systems
Fuse works on MacOSX too, not sure about windows but I seem to remember something being done in that regard.
an implementation of FUSE on windos exists but isn’t open source. A GVFS backend would be better. Is the interface to produce GVFS backends public API now? Last I looked at GVFS, GVFS backends needed to be in-tree.
AFAIK it’s still private but there are now at least 2 projects with hacks to have out of tree backends – SynCE and the iPhone AFC backend. Though I think we need to see how well tracker works on Mac/Windows/Others before we worry about bashing fuse
Windows still wasn’t the best place for dbus last i heard, something that tracker and GVfs love.
Using fuse filesystems or even gvfs backends for search is not really a good idea. In fact, using a vfs abstraction for anything that is not a real honest-to-god file storage area is just setting up for fail.
The problems with it (as experienced many times in the history of gnome with e.g. gnome-vfs vfolders, fonts:, etc) are multiple:
* It creates aliases in the namespace
Suddenly each file can be accessed via many uris. We get things like duplicated recent files entries, multiple places to store metadata for one file. Code missing that a copy from a to b actually is a replace because they are the same file, etc.
* Slow indirect file references
Suddenly we’re opening all sorts of files via an indirect type of uri, going via multiple layers. There is all sort of slow IPC happenings even for local files, and code that expect features like mmap or random file seeks for local files just break.
* semantics are often not compatible with storage
Its easy to throw up any random fuse or gvfs backend that does “funky stuff”. However, even if the API is very flexible with what you can do in a filesystem applications have a very specific set of expectations for how a filesystem works, and is prone to break in weird ways if you diverge from this. For instance, fuse using apps expect posix local file semantics, and gvfs apps expect the slightly more relaxed gio semantics.
Suddenly you get things like editing file contents changing the name of the file (since its some autogenerated from an index in a search result or whatnot) which confuses nautilus and causes it to not refresh correctly. (Been there with vfolders… ick)
* Mounts are not very dynamic to query changes
Both gvfs and fuse are based on the “mount” concept. This is not really very nice for something as dynamic as a query that changes constantly as you edit the query in the UI.
These kinds of issues is is why nautilus does searches and search folders using an internal mechanism rather than via gvfs.
Well I was thinking of other ‘nixes rather than windows. Also whats the config needed to make fuse mount the drive?
One of the nice things about having it in GVFS is you could just do music:// and it would work without any config (of course it would be cool if you could also do sparql stuff via URls EG music://?artist=blah music://?search=blah&artist=blah2 etc)
I’m the author of FSter, I would thank for the mention to the project and reply to the many comments about the scope.
I agree about the fact a GIO backend would be far better, and even better a full SPARQL interface to Tracker, but the main goal of the FSter effort is to provide instant access to semantic hierarchies for “legacy” applications, even not related to the Gnome environment (e.g.: OpenOffice). We cannot look for a full semantic desktop without take consideration for the many existing applications, built to work on a classic POSIX filesystem and useful (or even strictly required) to actual users; the shift has to be as smooth as possible, granting old functionalities and adding new ones in parallel.
@Alexander: I agree, a VFS is pretty much a hack for this functionality. What would be your suggestion for implementing this ‘properly’? Would it be possible to do as a nautilus plugin?
Thanks.
Love it! Karl you rock!
Rob:
Nautilus already supports search folders.
Got to a nautilus window, do a search and then File -> “Save search as…”.
@Alexl: Ok, so we have tracker 0.7+ support in tree now for vfolders, I see
So what’s really missing here is UI – I might be being stupid but I can’t see how to make a search for a given mime type without hand-creating a query.
Also, it’d be nice if we could support nepomuk type searching in search folders. Showing all nmo:Video isn’t quite the same as a query for a predefined list of mime types.
rob:
I think its possible. Go to search and type something, then click on the ‘+’ button which should give a new line, chose File type, and then “Other type” in the list. This should show all mimetypes on the system (although by description rather than mimetype).
I’m not saying this is an ideal UI or anything, but we do have something.
Also, historicaly we had pluggable search backends so needed a generic format for the query. Now that we only support tracker we could use a query language more tied to tracker.
@alexl: That sounds like a good plan to me! I’ll poke the UX guys to think a bit about the UI, and see if I can get someone to look at ways to put a sparql query in the vfolders format. Exciting!