Hello hackers, While following along with the nearby investigation into weird cross-version Apple toolchain issues that confuse configure, I noticed that the newer buildfarm Macs say:
checking for fdatasync... (cached) yes That's a bit strange because there's no man page and no declaration: checking whether fdatasync is declared... (cached) no That's no obstacle for us, because c.h does: #if defined(HAVE_FDATASYNC) && !HAVE_DECL_FDATASYNC extern int fdatasync(int fildes); #endif So... does this unreleased function flush drive caches? We know that fsync(2) doesn't, based on Apple's advice[1] for databases hackers to call fcntl(fd, F_FULLSYNC, 0) instead. We do that. Speaking as an armchair Internet Unix detective, my guess is: no. In the source[2] we can see that there is a real system call table entry and VFS support, so there is *something* wired up to this lever. On the other hand, it shares code with fsync(2), and I suppose that fdatasync(2) isn't going to do *more* than fsync(2). But who knows? Not only is it unreleased, but below VNOP_FSYNC() you reach closed source file system code. That was fun, but now I'm asking myself: do we really want to use an IO synchronisation facility that's not declared by the vendor? I see that our declaration goes back 20 years to 33cc5d8a, which introduced fdatasync(2). The discussion from the time[3] makes it clear that the OS support was very patchy and thin back then. Just by the way, another fun thing I learned about libSystem while reading up on Big Sur changes is that the system libraries are no longer on the file system. dlopen() is magical. [1] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fsync.2.html [2] https://github.com/apple/darwin-xnu/blob/d4061fb0260b3ed486147341b72468f836ed6c8f/bsd/vfs/vfs_syscalls.c#L7708 [3] https://www.postgresql.org/message-id/flat/200102171805.NAA24180%40candle.pha.pa.us
