On Tue, 23 Apr 2024 at 15:24, Antonio SJ Musumeci <trapexit@xxxxxxxxxx> wrote: > From the write(2) manpage (at least on Ubuntu): > > "Other errors may occur, depending on the object connected to fd." > > My argument has been that this note is defacto true generally. Yes. > > The specifics of this thread stem from close() returning EBADF to the > client app while talking to a FUSE server after the open() succeeded > and, from the point of view of the client app, returned a valid file > descriptor. Sounds like a bug in the FUSE server rather than something > FUSE itself needs to worry about. Return value from close is ignored in 99% of cases. It is quite hard to imagine this making real difference to an application. The basic philosophy of the linux kernel is pragmatism: if it matters in a real world use case, then we care, otherwise we don't. I don't think a server returning EBADF matters in real life, but if it is, then we do need to take care of it. > This is not unlike a recent complaint that when link() is not > implemented libfuse returns ENOSYS rather than EPERM. As I pointed out > in that situation EPERM is not universally defined as meaning "not > implemented by filesystem" like used in Linux. Doesn't mean it isn't > used (I didn't check) but it isn't defined as such in docs. ENOSYS is a good example where fuse does need to filter out errors, since applications do interpret ENOSYS as "kernel doesn't implement this syscall" and fuse actually uses ENOSYS for a different purpose. Thanks, Miklos
