site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On May 25, 2005, at 2:40 PM, darwin-dev-request@lists.apple.com 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. And why, even after I've removed foo.txt and imported bar/bar.txt, hasn't it been updated yet in line 20? 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. -Mark _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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". 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. This email sent to site_archiver@lists.apple.com