How to use entry_timeout and attr_timeout in FUSE/OSXFUSE low-level API?

Question

Is there any way to safely use non-zero timeouts in non-readonly filesystems? I cannot seem to find one. A couple of counter-examples:

Example One (non-zero negative entry timeout):

1. An application calls stat() and gets ENOENT;
2. calls create();
3. calls stat(), expecting success, but gets ENOENT instead because of negative entry timeout, so it concludes the FS is broken/inconsistent/etc.

Example Two (non-zero attr timeout):

1. An application calls utimes();
2. calls stat(), but gets stale values and concludes the FS is broken/inconsistent/etc.

I cannot come up with a counterexample for a positive entry timeout - it seems that even if lookup() returns some stale inode, the filesystem still can return ENOENT for the later getattr() call.

But what about the above 2 examples?

Answer 1

Just for reference, the same question was posted on the FUSE mailing list.

Here's the answer from Kyle Lippincott on why non-zero timeouts work:

If the create() goes through the kernel, it invalidates the negative entry timeout. If the create happens externally, then the timeout still holds.

Quoting Goswin von Brederlow on when non-zero timeouts are a problem:

Caching only works correctly if you implement a disk based filesystem, one where only the fuse process can alter metadata and all access goes only through fuse. Any overlay filesystem where something can change the underlying filesystem without going through fuse can run into inconsistencies.

So if you're e.g. building a network file system that allows multiple hosts to change the data you might get problems with non-zero timeouts.