site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com What happens after that synchronous call returns...? Are you expecting it to lock out the file system from any other access? It other words a synchronous call serves no purpose since at any moment another thread can come along and modify the state of the file system as long as it is mounted and writable. But all the filesystem operations _do_ have transactional semantics. -pmb _______________________________________________ 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... At 1:35 PM -0800 11/30/05, Dave Yost wrote: At 12:22 PM -0800 2005-11-30, Shawn Erickson wrote: On 11/30/05, Dave Yost <ListMailForDave@yost.com> wrote: At 01:32 PM -0800 2005-11-29, Mark Day wrote:
On Nov 29, 2005, at 12:03 PM, darwin-dev-request@lists.apple.com wrote:
that's what sync(2) does.
It doesn't seem to.
Beware that sync(2) is an asynchronous call. It just begins the flushing of data to all volumes. If you're reading the disk immediately, the changes may not have been written yet. Surely there should be a synchronous call one can use.
Well, it could be specified to guarantee that on return, everything that was dirty at the time of the call has been flushed to disk, whether or not anything has been modified during the interval. That is a purpose that would be served. Someday, I wish for a file system that is really a true database, with transactional semantics. The issue here is that someone is trying to read from the disk _behind the back_ of the filesystem. There is NO provision for that while the filesystem is in use. This email sent to site_archiver@lists.apple.com