Hi! On Fri, Aug 04, 2023 at 12:07:38PM +0200, Guillem Jover wrote: > On Thu, 2023-08-03 at 16:20:10 +0200, наб wrote: > > On Thu, Aug 03, 2023 at 03:22:50PM +0200, Alejandro Colomar wrote: > > > > diff --git a/man2/fsync.2 b/man2/fsync.2 > > > > index 1043e6a1b..9ced40b28 100644 > > > > --- a/man2/fsync.2 > > > > +++ b/man2/fsync.2 > > > > @@ -155,12 +155,6 @@ .SH VERSIONS > > > > .\" POSIX.1-2001: It shall be defined to -1 or 0 or 200112L. > > > > .\" -1: unavailable, 0: ask using sysconf(). > > > > .\" glibc defines them to 1. > > > > -.PP > > > > -On some UNIX systems (but not Linux), > > > > -.I fd > > > > -must be a > > > > -.I writable > > > > -file descriptor. > > > But that's still true. HP-UX and AIX had that issue. I'd move > > > that paragraph to HISTORY, and say "some old UNIX systems". > > Apparently still true on AIX, fsync(2) "Last Updated: 2023-03-24" > > (https://www.ibm.com/docs/en/aix/7.3?topic=f-fsync-fsync-range-subroutine) > > says > > Note: The file identified by the FileDescriptor parameter must be open > > for writing when the fsync subroutine is issued or the call is > > unsuccessful. This restriction was not enforced in BSD systems. The > > fsync_range subroutine does not require write access. > > and > > EBADF The FileDescriptor parameter is not a valid file descriptor > > open for writing. > Yes. Also from current dpkg git HEAD on "AIX power8-aix 2 7 00F9C1964C00": > checking whether fsync works on directories... no > out of: > https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/m4/dpkg-funcs.m4#n28 > > > So this purely-nominal restriction is likely to go away because > > Issue 8 requires directories to be fsync()able. It appears that classic > > UNIXes https://www.austingroupbugs.net/view.php?id=672 (comment 0001499) > > simply had no need for fsync() on directories and thus we > That's still not released though? And after skimming over the proposed > changes, I'm not sure they match reality either on Linux? For example, > the current amount of fsync() done by dpkg for all filesystem objects > (not just the db it had always historically done) was precisely to > avoid 0-sized files that it was getting on abrupt system termination > at least on ext3 and ext4(?). (I'm not sure whether this has improved > since then though, but at the time the Linux filesystem developers > pretty much said this was a problem with userland code as developers > were "writing buggy code".) Fair cop I s'pose, the directory wording is new in Draft 3. You should probably post to austin-group-l@ if you think they don't match reality under Linux. > My intention when I mentioned the currently documented behavior in 2012, > was to help other people that might stumble over this portability issue. > If the current documentation is not clear, then let's improve it. But > this update seems more confusing than helpful to me, in addition of > being wrong as there's no current POSIX version that forbids this. It's muddled by coupling it to the directory semantics which are clearly still in flux. I read, fsync(): 36407 ERRORS 36408 The fsync( ) function shall fail if: 36409 [EBADF] The fildes argument is not a valid descriptor. 36410 [EINTR] The fsync( ) function was interrupted by a signal. 36411 [EINVAL] The fildes argument does not refer to a file on which this operation is possible. 36412 [EIO] An I/O error occurred while reading from or writing to the file system. 36413 In the event that any of the queued I/O operations fail, fsync( ) shall return the error conditions 36414 defined for read( ) and write( ). 36417 APPLICATION USAGE 36418 The fsync( ) function should be used by programs which require modifications to a file to be 36419 completed before continuing; for example, a program which contains a simple transaction 36420 facility might use it to ensure that all modifications to a file or files caused by a transaction are 36421 recorded. 36422 An application that modifies a directory, for example, by creating a file in the directory, can 36423 invoke fsync( ) on the directory to ensure that the directory’s entries and file attributes are 36424 synchronized. For most applications, synchronizing the directory’s entries should not be 36425 necessary (see XBD Section 4.11, on page 98). I read, fdatasync(): 31161 ERRORS 31162 The fdatasync( ) function shall fail if: 31163 [EBADF] The fildes argument is not a valid file descriptor. 31164 [EINVAL] This implementation does not support synchronized I/O for this file. 31165 In the event that any of the queued I/O operations fail, fdatasync( ) shall return the error 31166 conditions defined for read( ) and write( ). 31169 APPLICATION USAGE 31170 Note that even if the file descriptor is not open for writing, if there are any pending write 31171 requests on the underlying file, then that I/O will be completed prior to the return of fdatasync( ). 31172 An application that modifies a directory, for example, by creating a file in the directory, can 31173 invoke fdatasync( ) on the directory to ensure that the directory’s entries are synchronized, 31174 although for most applications this should not be necessary (see XBD Section 4.11, on page 98). Synchronized I/O Data Integrity Completion: 2599 For the purpose of this definition, an operation that reads or searches a directory is considered to 2600 be a read operation, an operation that modifies a directory is considered to be a write operation, 2601 and a directory’s entries are considered to be the data read or written. As being able to f[data]sync() directories being required if the system supports the Synchronised I/O option or the File Synchronisation option. The first paragraph in fdatasync() APPLICATION USAGE appears in Issue 8 2016, which cites https://www.austingroupbugs.net/view.php?id=501 which fixes an editorial error by matching fdatasync() and aio_fsync() to fsync() in making EBADF only for invalid fds. So, prior to Issue 8, fsync() and fdatasync() are allowed to EINVAL if they get a directory (maybe in Issue 8 as well, sure, doesn't matter), but they are /not/ allowed to EBADF if the fd is not writable (for fdatasync() since 2016 by accident, and for fsync() since it was released in Issue 3). Thus, it's obvious to me that yes, the SysVr4 interface and HP-UX/AIX interfaces /are/ fundamentally broken and have /always/ been fundamentally broken, and that the actual semantics for fsync()ing directories, while defined in Issue 8 Draft 3, are irrelevant here. > > Replace the FUD that says that some UNIXes require the fd to be writable: > > they /must not/ and this confuses users: > > https://101010.pl/@eater@cijber.social/110824211348995583 > > with mentioning explicitly that HP-UX and AIX (by name) are just broken. > To me whether this is supposed to conform to some historic semantics > does not seem very relevant when making code portable, and when that > contradicts the specific system explicit documentation and behavior. > And then "FUD" seems completely out of line here (even though I didn't > write that man page update), and incorrect, because there _are_ such > systems in existence… Well, eater was denied progress out of fear of unportability due to uncertainty in the documentation, so, intentional or not, well. The correct way of spelling this is "HP-UX and AIX are broken and need fd to be opened for writing" and generalising this to a vague "some UNIX systems" is just needlessly hostile to the user. v3 in followup. Best,
Attachment:
signature.asc
Description: PGP signature
