site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com [ sync() being synchronous or not ] On a journaled HFS+ volume, sync is synchronous because we flush the in-memory transaction buffer and the last thing that does is a flush-track-cache command which will not complete until all the other i/o's are complete. The behavior of other file systems is "mostly" synchronous. That is, they can issue async writes but after about 30 or so they will block on the queue of pending i/o going into the driver. In the worst case sync() could return with up to about 30 i/o's pending for a file system (on a local disk). Of course if you issue an fsync() on a file descriptor, that is *always* fully synchronous and will not return until the data is flushed. Having said all that, anyone that goes behind the back of the file system to read on disk data structures while the file system is still mounted is on thin ice. You can guarantee that we will break you in future releases. The functionality requested by the original poster is easily obtained with the PBCatSearch() interface. If you need sample code I can send it to you. It's a very fast way to search for files on an HFS file system. User level transactions would be very nice. It's not an easy problem though and definitely not something one can easily retrofit on existing file systems. As you surmise, writing a temp file, calling fsync() and then doing a rename() is the proper way to handle this. Of course user-level transactions are still a good thing but rename() (or the macos 9 style exchangedata()) give you most of what you need without the complexity of user level transactions. --dominic _______________________________________________ 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... Someday, I wish for a file system that is really a true database, with transactional semantics. They have transactional semantics in that each individual operation is atomic That's not even true. If you do this: create-write1-write2-write3-close and the system crashes, the result must be one of: .... I suppose you could write the file as a temp file, do a synchronous flush of the file, then move it into place. This is of course, a hack on top of an API that was never designed to be transactional. And you could still end up with a temp file lying around This email sent to site_archiver@lists.apple.com