Re: Filesystem View
Re: Filesystem View
- Subject: Re: Filesystem View
- From: Mike Smith <email@hidden>
- Date: Thu, 19 May 2005 22:24:09 -0700
On May 19, 2005, at 4:18 PM, Hamish Allan wrote:
Hi Mike,
Many thanks for your reply. What I really want to do is create a
filesystem in which Spotlight queries map directly to paths, e.g.:
$ ls /.spotlightfs/kMDItemFSName==\'test.txt\'/
would give you the same result as:
$ mdfind "kMDItemFSName=='test.txt'"
This shares some common ground with volfs, in that a readdir
in /.spotlightfs/ would yield only . and .. (as enumerating all
the possible entries would make no sense). Also, like volfs it
should report identical inode numbers for the files it references
(i.e., they should be akin to hard links). However, as you say I
would want it to behave like WebDAVfs in caching its results (using
kernel notification or "live updates" in Spotlight terminology).
Having thought about this some more I realise, given that MDQuery
apparently requires a run loop to yield results (although the
documentation says it can run synchronously), I would probably need
a daemon process to take queries from feed results to my filesystem
(via Mach messages?). It strikes me that the process "mds" is
already that daemon (feeding results to the MDQuery), and it would
be a shame to duplicate the functionality, but I don't suppose you
know how MDQuery and the mds daemon actually communicate?
You're *so* close to WebDAV in some regards here it's just not funny;
you really need to go look at it, I believe it's open-sourced.
One thing that you want to consider here is whether you want queries
to map to files or directories. I would be inclined to go with the
latter, myself, since many queries will yield more than one result
(imagine you had two files called 'test.txt' in the above case).
How you chose to back the filesystem is really up to you; one
approach would simply be to populate the 'cache' directories with
symbolic links to the actual files/folders. Another would be to
redirect lookups across to the real filesystem. A third (more like
WebDAVfs) would be to have the fsnode hold a reference to the 'real'
vnode.
The drawback with the WebDAVfs approach in your case is that
modifications to a file might have the effect of moving it out of the
'directory' (because it no longer matches the query), and so the
'path' to the file might change in ways that an application would not
be happy about.
A problem with the symlink approach would be that it would not be
possible to have those files be the 'real' files, so you couldn't
e.g. delete them, or move them en masse. This isn't so much a
problem because you can get this sort of behaviour with the Finder
search box already.
It's an interesting problem; have fun with it!
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden