PR_Open's PR_SYNC flag is not implemented on the Mac. The PR_SYNC flag is modeled after the O_SYNC flag of Unix's open() system call. If PR_SYNC is specified, each write will wait for both the file data and file status to be physically updated.

Set target milestone to M6.

Offloading some of gordon's doomage

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

Deferring to M7 as this isn't a showstopper for M6.

We may want to close this bug as a WONTFIX. To actually force a write to media we'd have to flush the volume after each which may not be desirable from the performance standpoint. Gordon has pointed out to me that on the Mac it isn't necessary to flush the file after each write if what you're trying for is inter- process file synchronization.

2nd line on previous comment should start: we'd have to flush the volume after each write which may not be desirable ^^^^^

Per wtc's suggestion marking this LATER instead of WONTFIX so that when/if we've got an OS on the Mac that supports/needs sync writes we can address the issue.

phillip gone, removing him from qa contact, sorry for spam

reopening all latered bugs

Moving all latered bugs to M20 as ordered by project manager. Although these bugs are now open, assigned and targetted, XPToolkit has no plans to fix/implement them in the current release cycle, if ever.

Mass move of all M20 bugs to M30.

Set target milestone "NSPR 4.1". Steve, is it possible to implement the PR_SYNC flag on Mac? PR_SYNC is modeled after the Unix O_SYNC flag. It means that PR_Write() does not return until the data has been written to the disk. See http://www.opengroup.org/onlinepubs/007908799/xsh/open.html (which doesn't explain O_SYNC clearly) or the "open" man page on Unix.

I think all we would have to do is flush the volume afert writing. This slows down the call, but it guarantees the data to be written to disk. Even closing a file however, doesn't guarantee that information is written to disk, until PBFlushVol is called.

Also, PBFlushFile will make sure the data is written to disk, but it doesn't necessarily write the catalog and extents entries to disk. This means if a write to a file extends the file, and a crash occurs before FlushVol is called, even if PBFlushFile has been called, the file will appear to have it's old EOF and extents, but whatever new data was written before the crash.

Would PBFlushFile be cheaper than PBFlushVol, or do we really need to call PBFlushVol? The Mac implementation of PR_Sync calls PBFlushFile. (Note that PR_Sync is a function while PR_SYNC is a flag for the PR_Open function.) Is it possible to open a file so that flush is automatically done by the OS? Otherwise, we'll have to emulate it by calling PBFlushVol or PBFlushFile after every write. This emulation would suffer from the non-atomicity problem that you just described.

Can't fix this in time for NSPR 4.1.

Revisiting old open bugs... With the impending dropping of support for Mac OS versions prior to Mac OS X and the move to a mach-o based build when Mac NSPR is basically BSD *nix NSPR can this bug be retired?

Per Wan-Teh's agreement closing WONTFIX