site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Hi, -- Terry _______________________________________________ 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... On May 13, 2008, at 8:30 AM, Andre-John Mas wrote: I came across this article this morning, by way of Gizmodo, and though it might be of interest for the list, since it also apparently effects MacOS X: http://osnews.com/story/19731/The-25-Year-Old-UNIX-Bug The code was valid until BSD 4.4, which attempted to abstract the struct dirent and struct direct to abstract UFS dependence. It remained valid in BSD 4.3 because of the intentional "coincidence" in the structures, which was done for performance reasons. The issue is deletion of the directory entry in a directory entry block in UFS internalizing an d_ino value of zero as an implementation detail, and expecting it to have been externalized as a copy of the on disk structure. Technically, the fix that was published is incorrect. The correct fix is to not externalize the entry outside of UFS, and to remove the workaround code, since deleted files at the start of some arbitrary block boundary are not going to result in 0 d_ino values on other file systems. Also, technically, there is no way to reasonable solve the problem here, as directories are not snap-shotted nor is a mandatory write lock asserted when a DIR * is returned, and held until the DIR * is disposed. Any interleaved operations which modify the directory under UFS can still trigger block compaction, entry coelescing, or directory truncation (if the end could end up with one or more trailing empty blocks). This includes not only deletes and creates, but also renames, if the new name will not fit in the old entry record. Using telldir() values across the underlying getdirentries() block boundaries from which readdir() gets its data is simply not safe for most file systems. This email sent to site_archiver@lists.apple.com