Under FreeBSD, flush() return value is ignored

[asomers]

The documentation for the flush method says that it can be used "if a filesystem wants to return write errors in close()" while noting that "many applications ignore close(2) errors". However, the problem is bigger than "many applications ignore close(2) errors", because many kernels don't even deliver them.

POSIX says that "The close() operation itself need not block awaiting such I/O completion.", so a FUSE filesystem can't assume that an application will ever see an error returned by flush.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html

Indeed, FreeBSD's close implementation does not wait, so it has no opportunity to return flush errors to the application.

Linux's close(2) implementation does appear to return EIO errors (I haven't checked the source), but still the man page says "A successful close does not guarantee that the data has been successfully saved to disk", which means that an application programmer can never rely on the absence of errors from close to mean anything.

Given this limitation, a FUSE filesystem can never rely on errors returned by flush to even be delivered. So I think the documentation should be revised to suggest that the return value will be ignored. However, in that case there wouldn't seem to be any remaining purpose to flush? Perhaps the method should be deprecated?

cc @cemeyer

[Nikratio]

Thanks for the report! You're probably right for a generic POSIX system. Under Linux, however, errors returned by FUSE's flush() handler are guaranteed to be be returned to the user in the close() return value. If FreeBSD does this differently, then this would be a bug in FreeBSD's FUSE implementation (which, as I understand, is designed to be API compatible with the Linux reference). If that's the case, then it would indeed be nice to point this out in the documentation, but we should link to some authoritative source (e.g. an issue in the FreeBSD bug tracker or the part of the source code where this is visible).

Would you be able to create a pull request?

[asomers]

It's not really a bug in FreeBSD's fuse implementation, because the problem isn't in fuse itself. The problem is just that close(2) simply doesn't return this type of error on FreeBSD. The bug, if you could call it that, is that libfuse assumes non-portable behavior. I could make try to make that more clear.