site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 25 May 2005, at 18:03, Mike Smith wrote: I'm starting to get an impression! 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 Thanks, 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... Ah, you have no idea the can of worms into which you blithely dip. 8) 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. Okay, I think I understand, but that still doesn't fully explain the following behaviour: 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? 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 I understand this now. So to find out a file's name from its vnode I ask the filesystem for a directory listing on the vnode in its parent cache (and to find out its pathname I do that recursively). 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? How would you know which path to return? 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. 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. Isn't that what Spotlight is: a user process attempting to run in lockstep with the filesystem by means of the fsevents API?! Build your structure lazily in response to user requests rather than dragging the whole system down to a crawl. I figured that essentially I would be using part of the filesystem as a cache for search results, with the option of having that cache updated live. So there would be as many threads alive as live smart folders, but most of them would be idle most of the time. I hadn't really considered that this would adversely affect performance because I've never used a lot of smart folders, but it may not scale well to other users. You're definitely better off building your filesystem as a proper VFS module. I haven't found a great deal of information about how to go about this. I have gleaned bits and pieces, like that I should bundle this into a kext, without an explanation of how. Also I have little to no idea about how to debug kernel code. Any pointers, anyone? This email sent to site_archiver@lists.apple.com