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.
