4 ms·

Off topic: what type of error can occur when closing a file? Is it somehow possible that the kernel denies your request, and forces your handle to stay open?

by SCHiM 4y ago

TheDong 4y ago
Quoting from "man 2 close": https://man7.org/linux/man-pages/man2/close.2.html https://man7.org/linux/man-pages/man2/close.2.html > it is quite possible that errors on a previous write(2) operation are reported only on the final close() ... Failing to check the return value when closing a file may lead to silent loss of data. > the behavior that occurs on Linux ... the file descriptor is guaranteed to be closed. So yeah, it's always closed on linux, but POSIX doesn't guarantee that for EINTR specifically, and there are sometimes meaningful errors.
- lilyball 4y ago
  FWIW Rust automatically retries the operation on EINTR.
- dllthomas 4y ago
  > Failing to check the return value when closing a file may lead to silent loss of data. Checking, on the other hand, probably makes it loud loss of data.
  - turminal 4y ago
    Why would it? If you care enough to check you probably also care enough not to discard the data you attempted to write.
    - dllthomas 4y ago
      I was referring to checking because "you should check" when you don't actually care enough to structure your program around not losing the data. It's easy to to check and emit a diagnostic, it's harder to make sure you have collected the data you've written to a file descriptor and have something sensible to do with it if the close fails.
deleted 4y ago
[deleted]
hu3 4y ago
Great question! Here is a better explanation than I could write: https://www.joeshaw.org/dont-defer-close-on-writable-files https://www.joeshaw.org/dont-defer-close-on-writable-files In resume, man close(2), gives us the potential errors. This is the output for Ubuntu 20.04 LTS: EBADF fd isn't a valid open file descriptor. EINTR The close() call was interrupted by a signal; see signal(7). EIO An I/O error occurred. ENOSPC, EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent write(2), fsync(2), or close().
colonwqbang 4y ago
One situation is that you close something twice or otherwise try to close an invalid fd. Still, it's very common to ignore the return value of close. If you use NFS or other specific drivers you can probably get more interesting errors.
anitil 4y ago
Other comments have mentioned _how_, I figured I'd mention a couple of scenarios that this could create. Programs that fork/exec will typically close all their open file descriptors, so if a close fails (like an EINTR) it's possible a child could inherit an open file descriptor for a file that they otherwise wouldn't have access to. File descriptors are also a finite resource so if you're opening and closing thousands of files you could run out. Both situations are unlikely, but I'm sure somebody has had their day ruined by these.

Off topic: what type of error can occur when closing a file? Is it somehow possible that the kernel denies your request, and forces your handle to stay open?

by SCHiM 4y ago

Off topic: what type of error can occur when closing a file? Is it somehow possible that the kernel denies your request, and forces your handle to stay open?

TheDong 4y ago

Quoting from "man 2 close": https://man7.org/linux/man-pages/man2/close.2.html https://man7.org/linux/man-pages/man2/close.2.html > it is quite possible that errors on a previous write(2) operation are reported only on the final close() ... Failing to check the return value when closing a file may lead to silent loss of data. > the behavior that occurs on Linux ... the file descriptor is guaranteed to be closed. So yeah, it's always closed on linux, but POSIX doesn't guarantee that for EINTR specifically, and there are sometimes meaningful errors.

lilyball 4y ago
FWIW Rust automatically retries the operation on EINTR.
dllthomas 4y ago
> Failing to check the return value when closing a file may lead to silent loss of data. Checking, on the other hand, probably makes it loud loss of data.
- turminal 4y ago
  Why would it? If you care enough to check you probably also care enough not to discard the data you attempted to write.
  - dllthomas 4y ago
    I was referring to checking because "you should check" when you don't actually care enough to structure your program around not losing the data. It's easy to to check and emit a diagnostic, it's harder to make sure you have collected the data you've written to a file descriptor and have something sensible to do with it if the close fails.

deleted 4y ago

[deleted]

hu3 4y ago

Great question! Here is a better explanation than I could write: https://www.joeshaw.org/dont-defer-close-on-writable-files https://www.joeshaw.org/dont-defer-close-on-writable-files In resume, man close(2), gives us the potential errors. This is the output for Ubuntu 20.04 LTS: EBADF fd isn't a valid open file descriptor. EINTR The close() call was interrupted by a signal; see signal(7). EIO An I/O error occurred. ENOSPC, EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent write(2), fsync(2), or close().

colonwqbang 4y ago

One situation is that you close something twice or otherwise try to close an invalid fd. Still, it's very common to ignore the return value of close. If you use NFS or other specific drivers you can probably get more interesting errors.

anitil 4y ago

Other comments have mentioned _how_, I figured I'd mention a couple of scenarios that this could create. Programs that fork/exec will typically close all their open file descriptors, so if a close fails (like an EINTR) it's possible a child could inherit an open file descriptor for a file that they otherwise wouldn't have access to. File descriptors are also a finite resource so if you're opening and closing thousands of files you could run out. Both situations are unlikely, but I'm sure somebody has had their day ruined by these.