Driver seems to cache file content after file descriptor closed

[E6ren]

I'm trying to use MacFUSE to achieve automatic decryption of a file system: when a user attempts to open an encrypted file, I will return another file descriptor of the decrypted file in the - (BOOL)openFileAtPath:mode:userData:error: to allow the user to automatically open the decrypted file.
Then the decrypted file's descriptor will be stored in userData.

But after the - (void)releaseFileAtPath:userData: called and the decrypted file descriptor closed, then I tried to copy the encrypted file outof MacFuse filesystem, I'll copied the decrypted content out.

When a file is copied from the MacFUSE file system to the Apple File System (APFS), are the contents of the copy controlled by MacFUSE? Is there any caching mechanism here?

[bfleischer]

Files can be mapped to memory by calling mmap(2). After mapping a file to memory, the corresponding file handle can be closed, but the file contents (in memory) can still be accessed even though there is currently no open file handle for the file. This is by design and controlled y the macOS kernel. From the POSIX specification:

The mmap() function adds an extra reference to the file associated with the file descriptor fildes which is not removed by a subsequent close() on that file descriptor. This reference is removed when there are no more mappings to the file.

Furthermore, macFUSE reuses file handles. This is the result of differences in the VFS layer between Linux and macOS. When the macFUSE kernel extension receives an open request it checks if there is already an open file handle for the file with compatible oflags and reuses it. You will receive a close callback when the last process using this file handle calls close(2).

When a file is copied from the MacFUSE file system to the Apple File System (APFS), are the contents of the copy controlled by MacFUSE? Is there any caching mechanism here?

macFUSE relies on the kernels Unified Buffer Cache (UBC) mechanism. UBC is required for supporting mmap(2) and improves performance greatly. By default, in case read requests can be satisfied using the cache, you will not receive read callbacks. However, there should always be an open file handle when a file is copied from a FUSE volume to a different volume.

[E6ren]

Hi Fleischer , thanks for your reply!
So macFUSE will reuses file handles and UBC, it also means, the open and read callbacks won't be called everytime, right?
But in some cases, I want to know every open and read request. Does MacFUSE currently have an interface to turn off these reuse functions?

[E6ren]

Another question maybe is it possible for MacFUSE to distinguish between open and copy requests from macOS?

[bfleischer]

So macFUSE will reuses file handles and UBC, it also means, the open and read callbacks won't be called everytime, right?

That's correct. Caching can be reduced to the bare minimum with the noubc mount option.

But in some cases, I want to know every open and read request. Does MacFUSE currently have an interface to turn off these reuse functions?

Unfortunately, this is not possible. The macFUSE kernel extension receives open and close callbacks, but there are no file handles on the VFS level of the macOS kernel. macFUSE could pass along every open callback to your file system daemon. But when the macFUSE kernel extension receives a close callback, it has no way of knowing which of the open file handles needs to be closed. I'm not aware of any way to resolve this. The only sane way of dealing with this is reusing file handles and implementing a use counter.

In case you are looking to prevent certain processes from opening a file on your volume, you might want to look into the Endpoint Security framework.

Another question maybe is it possible for MacFUSE to distinguish between open and copy requests from macOS?

This is not possible. It would be possible to implement some special handling of copy operation on the volume itself but not when crossing volume boundaries.