Theodore Ts'o wrote in <20250516124147.GB7158@xxxxxxx>: |On Fri, May 16, 2025 at 12:48:56PM +0200, Jan Kara wrote: |>> Now, POSIX.1-2024 says: |>> |>> If close() is interrupted by a signal that is to be caught, then |>> it is unspecified whether it returns -1 with errno set to |>> [EINTR] and fildes remaining open, or returns -1 with errno set |>> to [EINPROGRESS] and fildes being closed, or returns 0 to |>> indicate successful completion; [...] |>> |>> <https://pubs.opengroup.org/onlinepubs/9799919799/functions/close.html> |>> |>> Which seems to bless HP-UX and screw all the others, requiring them to |>> report EINPROGRESS. |>> |>> Was there any discussion about what to do in the Linux kernel? |> |> I'm not aware of any discussions but indeed we are returning EINTR while |> closing the fd. Frankly, changing the error code we return in that \ |> case is |> really asking for userspace regressions so I'm of the opinion we just |> ignore the standard as in my opinion it goes against a long established |> reality. | |Yeah, it appears that the Austin Group has lost all connection with |reality, and we should treat POSIX 2024 accordingly. Not breaking |userspace applications is way more important that POSIX 2024 |compliance. Which is sad, because I used to really care about POSIX.1 |standard as being very useful. But that seems to be no longer the |case... They could not do otherwise than talking the status quo, i think. They have explicitly added posix_close() which overcomes the problem (for those operating systems which actually act like that). There is a long RATIONALE on this, it starts on page 747 :) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
