site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 26 May 2005, at 23:31, Mark Day wrote: I'll do so. Presumably you'll do so as well? ;) Actually, no! Instead the mdfind in line 14 finds nothing whatsoever. Best wishes, Hamish _______________________________________________ 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... 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. Personally, I would have just a list of parent nodes, then anything which cares can ask for a readdir on those nodes recursively to find the whole path. 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?) Well, yes and no. No more so that in the current situation, really. What I really want to know is, what does Spotlight do? Because it would appear that it only stores vnodes rather than paths, yet if I perform a Spotlight query first thing after a reboot, it doesn't seem to take any more time to return results. This email sent to site_archiver@lists.apple.com