Re: Darwin-dev Digest, Vol 2, Issue 125
Re: Darwin-dev Digest, Vol 2, Issue 125
- Subject: Re: Darwin-dev Digest, Vol 2, Issue 125
- From: Mark Day <email@hidden>
- Date: Thu, 26 May 2005 15:31:00 -0700
On May 25, 2005, at 2:40 PM, email@hidden wrote:
Okay, I think I understand, but that still doesn't fully explain the
following behaviour:
1) $ mdfind hamishtest3
2) $ cat > foo.txt
3) hamishtest3
4) ^D
5) $ mdfind hamishtest3
6) /Users/hamish/foo.txt
7) $ mkdir bar
8) $ ln foo.txt bar/bar.txt
9) $ mdfind hamishtest3
10) /Users/hamish/foo.txt
11) $ cat >> bar/bar.txt
12) extra
13) ^D
14) $ mdfind hamishtest3
15) /Users/hamish/bar/foo.txt
16) $ rm foo.txt
17) $ mdfind hamishtest3
18) $ mdimport bar/bar.txt
19) $ mdfind hamishtest3
20) /Users/hamish/bar/foo.txt
In line 15 above, the last time the vnode for foo.txt was looked up
was via /Users/hamish/bar/, so that's where foo.txt is reported.
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.
At about line 11, the lookup of bar/bar.txt caused the parent
directory associated with the (bar.txt and foo.txt) vnode to become
the bar directory. It probably should have also changed the name
associated with the vnode to bar.txt. It would be worth filing a bug
on that.
And why, even after I've removed foo.txt
and imported bar/bar.txt, hasn't it been updated yet in line 20?
Because the vnode continued to exist for the entire duration, leaving
the vnode's associated name and parent unchanged. Had the vnode been
recycled and looked up again, that lookup would have created a new
vnode with new parent and name.
For a fun experiment, try the following between lines 13 and 14:
$ find -x /System -ls &> /dev/null
I'll bet that the output in line 15 would be "/Users/hamish/bar/
bar.txt".
It would be good if you could return all of them: anything which
would want a vnode-to-path-lookup would surely benefit from having
them all? Instead of caching a single parent node, you would maintain
a linked list (or whatever) of all parent nodes.
First of all, it's not just a list of parent nodes. It would be a
list of (parent,name) tuples. And if you allowed hard links to
directories, it would have to be a list of complete paths from the root.
Note that you'd have to maintain this list both on disk and in
memory. (You'd want to get a list of all paths, regardless of
whether they were used recently to look up the file, right?) As far
as I know, NTFS is the only popular volume format that maintains this
kind of mapping from one "inode" to multiple directory entries.
It would certainly be more complex. I'd be concerned about locking
issues, though I haven't thought that out all the way.
-Mark
_______________________________________________
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