Fix Issue 21627 - macOS: std.stdio.File.sync does not guarantee to be…

[kubo39]

… written to disk

[dlang-bot]

Thanks for your pull request and interest in making D better, @kubo39! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21627	normal	macOS: std.stdio.File.sync does not guarantee to be written to disk

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7789"

[CyberShadow]

Looking around a bit, it looks like F_FULLFSYNC actually does something else than fsync on other POSIX platforms:

https://www.postgresql.org/message-id/a06010200be3da9564694@%5B17.202.21.231%5D

Important bit:

The behavior
of fsync() on MacOS X is the same as it is on every other version of
Unix since the dawn of time (well, since the introduction of fsync
anyway :-).

and

https://news.ycombinator.com/item?id=6792669

I'm actually surprised Apple is even willing to make the guarantees above about F_FULLFSYNC; I'd read it as, at best, only applying to Apple hardware, as if a third-party controller is doing something silly they can't really do much about that.

So, it looks like there is no equivalent to F_FULLFSYNC for other platforms.

Whatever we choose to do, we should document that as the intent of the function, so that it can be updated consistently with new APIs / platforms. One of two things:

• Do we want the function to (vaguely) submit the data to disk? In which case we should keep using fsync.
• Do we want the function to provide a best-effort maximum guarantee (as far as the OS API allows) that the data has been permanently saved? In which case this is a change in that direction but the documentation ought to be updated to reflect that.

Finally, there is the question if there are circumstances where D programs wouldn't want to use F_FULLFSYNC, in which case this change would be a performance regression for them.

[n8sh]

there is the question if there are circumstances where D programs wouldn't want to use F_FULLFSYNC, in which case this change would be a performance regression for them.

The one circumstance I can think of is if power loss to the storage device is believed to be impossible. Are there others?

[RazvanN7]

This link does not exist

[CyberShadow]

Works here?

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fcntl.2.html

[RazvanN7]

Hmm, it works now. I must have had a connection issue.

[RazvanN7]

At the minimum, I think that we should specify that fcntl is called using FULLSYNC. @kubo39 What is your stance on this?

[CyberShadow]

At the minimum, I think that we should specify that fcntl is called using FULLSYNC.

Not sure if that's how you meant it, but just in case I'll clarify that it already does (the text says "..., F_FULLFSYNC fcntl on Darwin, and ...".