site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On May 25, 2005, at 7:29 AM, Hamish Allan wrote: Ah, you have no idea the can of worms into which you blithely dip. 8) This is not quite correct. How would you know which path to return? = Mike _______________________________________________ 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... But I don't really understand why this is the case -- surely a DELETE refers not to a vnode, but to an index entry, in which case the correct string ought to be able to be reported? Presumably there is an inverted index (from vnode to path) for every vnode on the filesystem. This must be populated at startup time, as Spotlight returns hamishtest2 for my mdfind query after a reboot. But the behaviour would suggest that although it can be added to for a fresh vnode, the entry for an existing vnode cannot be updated. And the entry is only cleared when the link count reaches zero. There is a cache of names by which a vnode has been looked up; just terminal name components. There is a child->parent relationship maintained between a vnode and *one* parent in which it has been looked up. This cache is built as a side-effect of the lookup process, and persists in conjunction with the vnode cache. It's not assembled en masse at any particular point in time. The "path to vnode" is assembled by traversing these relationships; there are transformations in the filesystem under which they cannot be correctly maintained, and if a file is looked up by two different paths, only one can be returned. I think that if the inverted index allowed multiple paths to be stored for a vnode, the correct behaviour could be achieved. Of course, some of my assumptions may not be correct. Any thoughts? This email is quite long already, but I'll give you a brief outline of my application. You may remember that I posted to this list recently about writing a Spotlight filesystem (http:// lists.apple.com/archives/darwin-dev/2005/May/msg00229.html). I thought it might be possible to get similar functionality without writing a VFS by having a daemon monitor the creation of new directories (either in a particular place, or with Spotlight- searchable attributes) and fill them with hard links to Spotlight search results. To preserve the pathname of the files found, I would create the full directory structure within the given folder; I therefore wanted a way to monitor whether that structure had changed, in order to halt any live updating of results and turn it into a 'normal' folder Attempting to run a user process in lockstep with the filesystem is doomed from the start; don't do this. Build your structure lazily in response to user requests rather than dragging the whole system down to a crawl. You're definitely better off building your filesystem as a proper VFS module. This email sent to site_archiver@lists.apple.com