Re: fsevents oddities (was Re: EVFILT_VNODES?)
Re: fsevents oddities (was Re: EVFILT_VNODES?)
- Subject: Re: fsevents oddities (was Re: EVFILT_VNODES?)
- From: Hamish Allan <email@hidden>
- Date: Thu, 2 Jun 2005 01:52:24 +0100
On 1 Jun 2005, at 19:12, Mike Smith wrote:
On May 25, 2005, at 12:59 PM, Hamish Allan wrote:
But there is no file /Users/hamish/bar/foo.txt, and nor has there
ever been, so something is wrong with the caching. Whatever part
of the system is caching foo.txt shouldn't be doing so once the
write to bar/bar.txt has happened. And why, even after I've
removed foo.txt and imported bar/bar.txt, hasn't it been updated
yet in line 20?
foo.txt and bar.txt are the same file; it just has two names. Only
one of those names can be cached; in this case, it's the one by
which the file was first looked up.
I really meant to imply the question, "why would the cache not be
updated with the name by which the file was *most recently* looked up?"
Let's assume you have:
foo/bar.txt
baz/quxx.txt
Both bar.txt and quxx.txt are links to the same file. Now you have
to remember that the node was looked up as quxx.txt under baz, but
as bar.txt under foo.
Since all of that information can change as files are renamed, and
since there's no guarantee that a file will even have a name at
all, maintaining this information is a lot of work for very little
return.
Whereas with the current situation you remember that the node was
once looked up as bar.txt under foo, and provide that pathname
whether or not it still exists (even if a currently existing
pathname, e.g., quxx.txt under baz, has been used more recently).
This is slightly less work for considerably less (indeed, arguably
negative) return.
All that is required to implement what I would like is that each time
a vnode is associated with a parent vnode (e.g., creating a file or
hard link in a directory), you store the vnode number of the parent
along with the name of the child from the perspective of that parent,
and each time a vnode is disassociated from a parent (e.g., deleting
a file or hard link from a directory), you remove that stored
information (renaming a file being a dissociation plus association in
a single operation). Then you can always provide every fully-
qualified filename by which a vnode can be referenced (including
being able to detect if all links to file have been removed).
Instead, developers must get used to the idea that despite having a
vnode, or a file handle, they may not be able to get a path at
which it can be looked up.
They must have had to all the more so before vn_getpath() existed
(presumably it owes its existence to developers turning round and
saying, "okay, but it would be really useful if we could" and then
implementing a solution somewhat half-heartedly).
As far as I can tell I am not suggesting rocket science? Or am I
underestimating the cost of implementing what I would consider to be
a decent benefit?
At the very least, surely the current caching mechanism should
freshen the cache more often than it does?
Best wishes,
Hamish
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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