site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 1 Jun 2005, at 19:12, Mike Smith wrote: On May 25, 2005, at 12:59 PM, Hamish Allan wrote: Let's assume you have: foo/bar.txt baz/quxx.txt 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?" Both bar.txt and quxx.txt are links to the same file. Now you have to remember that the node was looked up as quxx.txt under baz, but as bar.txt under foo. Since all of that information can change as files are renamed, and since there's no guarantee that a file will even have a name at all, maintaining this information is a lot of work for very little return. 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. All that is required to implement what I would like is that each time a vnode is associated with a parent vnode (e.g., creating a file or hard link in a directory), you store the vnode number of the parent along with the name of the child from the perspective of that parent, and each time a vnode is disassociated from a parent (e.g., deleting a file or hard link from a directory), you remove that stored information (renaming a file being a dissociation plus association in a single operation). Then you can always provide every fully- qualified filename by which a vnode can be referenced (including being able to detect if all links to file have been removed). Instead, developers must get used to the idea that despite having a vnode, or a file handle, they may not be able to get a path at which it can be looked up. They must have had to all the more so before vn_getpath() existed (presumably it owes its existence to developers turning round and saying, "okay, but it would be really useful if we could" and then implementing a solution somewhat half-heartedly). 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? At the very least, surely the current caching mechanism should freshen the cache more often than it does? smime.p7s