Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Darwin-dev Digest, Vol 2, Issue 125

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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.