This is a shockingly hard problem, which the technique still doesn't get right even if the hardware cooperates. 1) If the filename provided is just a filename,

This is a shockingly hard problem, which the technique still doesn't get right even if the hardware cooperates. 1) If the filename provided is just a filename, then dirname (and parent) may not work as expected. You ought run it through realpath first. 2) What if the parent's parent hasn't been flushed? You need to recurse all the way up to "/". 3) Extending support for other POSIX systems will be tricky. The Austin group (keepers of POSIX development) had trouble with this. Some systems consider using open() on a directory a complete sin (you must use opendir()), some allow it read only but not with write, fsync() may require write permissions instead of just read, and opendir() may not produce an FD which you can ever convince fsync() to operate on (e.g. because no write permission). Indeed, the initial proposal from the Austin group was that all operations on directory entries should be atomic if the inode is also synced (which matches e.g. HPUX, one of the systems which strictly disallows any attempt at calling fsync() on a directory). Many other systems (Linux especially) obviously don't fit that model, it has some unpleasant performance implications, and overall no agreement was ever reached as to how to standardize it. As for testing, you might look at "Torturing Databases for Fun and Profit" (https://www.usenix.org/conference/osdi14/technical-sessions/presentation/zheng_mai https://www.usenix.org/conference/osdi14/technical-sessions/...) and "All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications" (https://www.usenix.org/conference/osdi14/technical-sessions/presentation/pillai https://www.usenix.org/conference/osdi14/technical-sessions/...) for detailed approaches. Good catch on Apple lying on fsync, btw. Not too many people know that one.