fsevents oddities (was Re: EVFILT_VNODES?)
fsevents oddities (was Re: EVFILT_VNODES?)
- Subject: fsevents oddities (was Re: EVFILT_VNODES?)
- From: Hamish Allan <email@hidden>
- Date: Wed, 25 May 2005 15:29:17 +0100
Hi Mike,
Thank you for your detailed reply. You are right that I have a
problem, but Spotlight has it too! For instance, if I initiate the
following query........
firstshell$ mdfind -live "kMDItemFSName=='hamishtest*'"
[Type ctrl-C to exit]
........Then in another shell I type........
secondshell$ touch hamishtest1
........I get an update in the first shell........
Query update: 1 matches
........Then if I type........
secondshell$ ln hamishtest1 hamishtest2
........I get nothing in the first shell, but if I restart the query
I get........
^C
firstshell$ mdfind -live "kMDItemFSName=='hamishtest*'"
/Users/hamish/hamishtest1
/Users/hamish/hamishtest1
[Type ctrl-C to exit]
........If I then use the second shell to remove hamishtest1, no
update, but if I run it again........
firstshell$ mdfind -live "kMDItemFSName=='hamishtest*'"
/Users/hamish/hamishtest1
[Type ctrl-C to exit]
........So now I have a file called hamishtest2, no file called
hamishtest1, and a query which returns hamishtest1!
You can see a related behaviour using Amit Singh's fslogger utility
(thank you to Sam for pointing this out), which uses the new fsevents
API:
firstshell$ sudo fslogger-1.0-beta
secondshell$ touch foo
secondshell$ ln foo bar
secondshell$ rm foo
secondshell$ rm bar
[firstshell stdout, edited for brevity:]
# Event type = CREATE FILE
VNODE 18 path = /Users/hamish/foo
# Event type = CREATE FILE
STRING 17 string = /Users/hamish/bar
# Event type = DELETE
STRING 18 string = /Users/hamish/foo
# Event type = DELETE
STRING 18 string = /Users/hamish/foo
It looks like fsevents is performing caching, as rebooting between
"rm foo" and "rm bar" causes the second DELETE to have the correct
string = /Users/hamish/bar. It looks as though the first CREATE FILE
might be setting this up, as it seems to create a relationship
between VNODE and path (whereas the hard link event just has STRING /
string).
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?
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.
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?
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
I should be fine with the existing fsevents API for this, because my
daemon process would always create new directories rather than link
to existing ones.
Thanks and best wishes,
Hamish
On 25 May 2005, at 07:41, Mike Smith wrote:
Can anyone tell me how it works? Or could anyone recommend an
efficient method for determining when a file in a given directory or
any of its subdirectories changes, for a potentially large number of
subdirectories?
As a general rule, there isn't one.
You're making a common mistake in associating "file" with "location".
File paths are indices used to locate files. There is no guarantee
that there
is exactly one index for a file, nor is there any way to
efficiently enumerate
all of the indices for a file. Once a file is open, there is a
direct relationship
between the descriptor and the vnode that does not require the
existence
of an index; this is how you can delete open files.
This means that when a file is modified, there's no guarantee that you
know "where" the file may be looked up; nor where it was looked up by
whomever is modifying it; nor where the user "thinks" it is. These
may be
three different locations.
Spotlight makes a number of specific assumptions about the
notifications
that it receives, and it is interested in a view of files that
sounds very different
from yours.
Without knowing a lot more about you application, I can't help you
much more;
perhaps you could describe what you're trying to achieve?
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gold.ac.uk
This email sent to email@hidden
_______________________________________________
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