Re: fsevents oddities (was Re: EVFILT_VNODES?)
Re: fsevents oddities (was Re: EVFILT_VNODES?)
- Subject: Re: fsevents oddities (was Re: EVFILT_VNODES?)
- From: Mike Smith <email@hidden>
- Date: Wed, 25 May 2005 10:03:55 -0700
On May 25, 2005, at 7:29 AM, Hamish Allan wrote:
But I don't really understand why this is the case -- surely a
DELETE refers not to a vnode, but to an index entry, in which case
the correct string ought to be able to be reported?
Ah, you have no idea the can of worms into which you blithely dip. 8)
Presumably there is an inverted index (from vnode to path) for
every vnode on the filesystem. This must be populated at startup
time, as Spotlight returns hamishtest2 for my mdfind query after a
reboot. But the behaviour would suggest that although it can be
added to for a fresh vnode, the entry for an existing vnode cannot
be updated. And the entry is only cleared when the link count
reaches zero.
This is not quite correct.
There is a cache of names by which a vnode has been looked up; just
terminal name components. There is a child->parent relationship
maintained between a vnode and *one* parent in which it has been
looked up. This cache is built as a side-effect of the lookup
process, and persists in conjunction with the vnode cache. It's not
assembled en masse at any particular point in time.
The "path to vnode" is assembled by traversing these relationships;
there are transformations in the filesystem under which they cannot
be correctly maintained, and if a file is looked up by two different
paths, only one can be returned.
I think that if the inverted index allowed multiple paths to be
stored for a vnode, the correct behaviour could be achieved. Of
course, some of my assumptions may not be correct. Any thoughts?
How would you know which path to return?
This email is quite long already, but I'll give you a brief outline
of my application. You may remember that I posted to this list
recently about writing a Spotlight filesystem (http://
lists.apple.com/archives/darwin-dev/2005/May/msg00229.html).
I thought it might be possible to get similar functionality without
writing a VFS by having a daemon monitor the creation of new
directories (either in a particular place, or with Spotlight-
searchable attributes) and fill them with hard links to Spotlight
search results. To preserve the pathname of the files found, I
would create the full directory structure within the given folder;
I therefore wanted a way to monitor whether that structure had
changed, in order to halt any live updating of results and turn it
into a 'normal' folder
Attempting to run a user process in lockstep with the filesystem is
doomed from the start; don't do this. Build your structure lazily in
response to user requests rather than dragging the whole system down
to a crawl. You're definitely better off building your filesystem as
a proper VFS module.
= 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