Re: EBADF returned from close() by FUSE

[Antonio SJ Musumeci <trapexit@spawn.link>]

On 4/19/24 13:18, The 8472 wrote:
>> Errnos are not *really* standard. They vary by
>> kernel release, different OSes, different libcs, different filesystems,
>> etc. As I pointed out recently to someone the use of EPERM to mean a
>> filesystem doesn't support "link" is not defined everywhere. Including
>> POSIX IIRC. And given FUSE is a cross platform protocol it shouldn't,
>> within reason, be interpreting any errors sent from the server (IMO).
> FUSE can send any errnos it wants over its client-server protocol.
> But the kernel could still translate them to error codes that don't
> have a documented meaning for a specific syscall.

No one is talking about or cares about the protocol error handling. That 
is private to the protocol. What matters is what FUSE kernel side does.

And I'd disagree with you because as I tried to point out that 
"documented meaning" is not set in stone. Things change over time. 
Different systems, different filesystems, etc. treat situations 
differently. Some platforms don't even have certain errno or conflate 
others. Aren't there even differences in errno across some Linux archs? 
This is just a fact of life. FUSE trying to make sense of that mess is 
just going to lead to more of a mess. IMO EIO is no better than EBADF. A 
lot of software don't handle handle EXDEV correctly let alone random 
other errnos. For years Apple's SMB server would return EIO for just 
about anything happening on the backend. If a FUSE server is sending 
back EBADF in flush then it is likely a bug or bad decision. Ask them to 
fix it.

And really... what is this translation table going to look like? `errno 
--list | wc -l` returns 134. You going to have huge switch statements on 
every single one of the couple dozen FUSE functions? Some of those  
maybe with special checks against arguments for the function too since 
many errno's are used to indicate multiple, sometimes entirely 
different, errors? It'd be a mess. And as a cross platform technology 
you'd need to define it as part of the protocol effectively. And it'd be 
backwards incompatible therefore optional.