site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the detailed explanation Quinn. I'll look into it more. On Aug 15, 2005, at 4:28 AM, Quinn wrote: At 18:37 -0500 12/8/05, Brian Bergstrand wrote: <http://developer.apple.com/technotes/tn2004/tn2124.html> Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDAOZEedHYW7bHtqIRAuz7AKC3HboLbvtF9rSRvfbqFc41KRBfswCgpDPp DHFxpKnfnV+ohZXneXmf2vE= =I94z -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... We've had problems with the Carbon File Mgr caching dir entries for too long in Panther and Jaguar and the problem persists in Tiger. Both the Finder and the File Manager cache directory contents. You need to distinguish between the two. The way to do that is to write a simple tool that iterates a directory using File Manager calls. If you're seeing stale data, the File Manager cache is the problem. OTOH, if the data is up-to-date, you need to look to the Finder. I believe that the enumeration cache is per-process. If so, your tool will to have to keep running between successive enumerations. You can dump the enumeration cache for a volume using PrintEnumerationCache, as described in Technote 2124 "Debugging Magic". As far as the File Manager is concerned, looking at the source, it seems that it caches directory contents based the modification time of the directory. To improve performance, it only rechecks the directory's modification time when a client starts an enumeration. You should make sure you're bumping the mod date of the directory when you make changes to the directory. The above applies only to Posix volumes; IIRC that's what you're implementing. If the Finder is the problem, I believe that, in 10.4 and later, the Finder will use kqueues to pick up changes to its windows. To see an example of (roughly) what the Finder does, take a look at the FileNotification sample. <http://developer.apple.com/samplecode/FileNotification/ FileNotification.html> In theory, if your file system notifies the system of changes, this will automatically bubble up through kqueues to the Finder. AFAIK you can do this will public KPIs. For an example of how to do this, search the HFS [Plus] source for "HFS_KNOTE". In practice, this isn't going to work because, looking at the Finder source, it seems that it contains a special case list of file systems that support kqueues. *grrrr* <rdar://problem/4216129> This email sent to site_archiver@lists.apple.com