4 ms·

> No one checks close()'s result because it lies. And since nobody checks the result of close and very few check the result of every single write operation, ma

> No one checks close()'s result because it lies. And since nobody checks the result of close and very few check the result of every single write operation, many "disk full" errors go unnoticed.

ncmncm 6y ago
If you want to know whether your writes are getting out, you will get a much more reliable indication from fsync(). So, instead of exhorting people to check close()'s result, you should exhort them to fsync() first and check that result. A very old programming principle says, "Never check for any failure you are not equipped to act on." It is sometimes used as a reminder to ensure you are always so equipped.
- rectang 6y ago
  My understanding is fsync() will tell you more than close() only when a flush of the OS cache fails to make it to disk. Is there anything else? The problem with calling fsync() is that you have to wait for it to finish. There are many scenarios where the extra data integrity guarantees you get from calling fsync() aren't important.
  - ncmncm 6y ago
    close() will fail to report a wide variety of failures. But Cesar is right, you can't re-try it. And fsync() can be very slow on most commonly-used file systems. We are fortunate that now SSDs are fast.
    - deleted 6y ago
      [deleted]
- Jweb_Guru 6y ago
  > A very old programming principle says, "Never check for any failure you are not equipped to act on." It is sometimes used as a reminder to ensure you are always so equipped. This sounds like a great principle for allowing dangerous bugs to linger in a codebase for years... one can always act upon a failure by aborting.
- einpoklum 6y ago
  fsync() is not part of the standard C library. You won't be able to use it on, say, MS Windows. (Although maybe rust has it?)
  - ncmncm 6y ago
    Neither are open(), close(), or, indeed, file descriptors. But they are all in Posix, which is ISO Standard 9945, based on IEEE 1003.1. Windos has various gestures toward Posix compatibility, which might include _close() and _fsync(). Unix and Posix file system semantics are not among the best achievements of the Unix philosophy or of Posix as a universal system interface, but they have been considered "good enough" by most for a long enough time to make an actually-good replacement increasingly unlikely to take hold.

> No one checks close()'s result because it lies. And since nobody checks the result of close and very few check the result of every single write operation, many "disk full" errors go unnoticed.

ncmncm 6y ago

If you want to know whether your writes are getting out, you will get a much more reliable indication from fsync(). So, instead of exhorting people to check close()'s result, you should exhort them to fsync() first and check that result. A very old programming principle says, "Never check for any failure you are not equipped to act on." It is sometimes used as a reminder to ensure you are always so equipped.

rectang 6y ago
My understanding is fsync() will tell you more than close() only when a flush of the OS cache fails to make it to disk. Is there anything else? The problem with calling fsync() is that you have to wait for it to finish. There are many scenarios where the extra data integrity guarantees you get from calling fsync() aren't important.
- ncmncm 6y ago
  close() will fail to report a wide variety of failures. But Cesar is right, you can't re-try it. And fsync() can be very slow on most commonly-used file systems. We are fortunate that now SSDs are fast.
  - deleted 6y ago
    [deleted]
Jweb_Guru 6y ago
> A very old programming principle says, "Never check for any failure you are not equipped to act on." It is sometimes used as a reminder to ensure you are always so equipped. This sounds like a great principle for allowing dangerous bugs to linger in a codebase for years... one can always act upon a failure by aborting.
einpoklum 6y ago
fsync() is not part of the standard C library. You won't be able to use it on, say, MS Windows. (Although maybe rust has it?)
- ncmncm 6y ago
  Neither are open(), close(), or, indeed, file descriptors. But they are all in Posix, which is ISO Standard 9945, based on IEEE 1003.1. Windos has various gestures toward Posix compatibility, which might include _close() and _fsync(). Unix and Posix file system semantics are not among the best achievements of the Unix philosophy or of Posix as a universal system interface, but they have been considered "good enough" by most for a long enough time to make an actually-good replacement increasingly unlikely to take hold.