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