site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 2 Jun 2005, at 05:16, Mike Smith wrote: I'm not sure I understand how MOU is relevant to this. 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... This email sent to site_archiver@lists.apple.com 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? foo.txt and bar.txt are the same file; it just has two names. Only one of those names can be cached; in this case, it's the one by which the file was first looked up. I really meant to imply the question, "why would the cache not be updated with the name by which the file was *most recently* looked up?" Why would any one name be more correct than any other? It's a losing game, unfortunately. Specifically, I have demonstrated a case where the parent vnode is updated without updating the cached filename, leading to a never- existent path /Users/hamish/bar/foo.txt, in which MRU would be more correct. Solitaire is also a losing game, but there are ways that you can play it which maximise your chances of winning. Whereas with the current situation you remember that the node was once looked up as bar.txt under foo, and provide that pathname whether or not it still exists (even if a currently existing pathname, e.g., quxx.txt under baz, has been used more recently). This is slightly less work for considerably less (indeed, arguably negative) return. It's O(1) work rather than O(N) work, and for the common case (i.e. where nobody is using hardlinks) it works well enough. For the common case (i.e. where nobody is using hardlinks) my suggestion is O(1). "It works well enough" is assuming the consequent -- this thread is about the cost/benefit tradeoff, and I think that misinformation is arguably less useful than no information. I think that "all that" is perhaps touchingly naive, but yes in theory there is no reason why multiple parent associations could not be maintained, however this is a lot of work for overall very little return. You might say the same about providing *any* sort of vn_getpath() operation. As far as I can tell I am not suggesting rocket science? Or am I underestimating the cost of implementing what I would consider to be a decent benefit? In providing *any* pathname for an extant vnode, the kernel is already making a dangerous guarantee. Encouraging further use of the interface just makes the consequences worse. All that the current implementation guarantees is that at some point, components of the returned path were components of a path or paths that once existed to a given vnode. Not even that the returned path was ever a path to the given vnode. What my suggestion guarantees is that at calling time, there existed such-and-such a path to a given vnode. Where's the danger in that? At the very least, surely the current caching mechanism should freshen the cache more often than it does? The tradeoffs between MRU and MOU are so bad that first-come is, in the end, no worse. smime.p7s