Is it possible the Init method is called slightly before the file system is ready? about cgofuse HOT 4 CLOSED

Yes, there are some unfortunate differences in how file system initialization happens in Linux/OSX vs Windows FUSE. These differences make it hard to rely on precise timings from Init.

On Linux/OSX Init() is an actual message sent by the kernel (FUSE_INIT). The kernel sends this message upon initializing the new mount. It usually follows up with a Statfs("/") to get information about the file system.

On Windows Init() is not called by the kernel, but the user mode FUSE layer. This unfortunately happens before file system creation. It is followed up by a Statfs("/") and Getattr("/") which also happen before file system creation. [link]

The reason that it had to be done like this, is that on WinFsp the file system creation API (FspFileSystemCreate ) requires to know a lot of the information about the file system upon starting up. In order to gather this information it calls Statfs and Getattr on the root directory, but this also means that it must call Init before hand (or it would break the FUSE contract and call file system methods before Init).

I cannot think of a good fix for this, other than making it more clear in the documentation that there are no guarantees regarding Init timings.

from cgofuse.

Changing the docs seems like a good plan.

Will do.

Any ideas on how to detect the FS is ready? Perhaps doing a before and after stat on the mountpoint would tell you if the (st_dev, st_ino) changed?

That would require polling but would work on UNIX. I do not think it would work on Windows.

On Windows you can mount on drives or directories. Mounting is different from UNIX, because the drive or directory must not exist prior to mounting. So you can poll to see if the expected drive/directory pops up. Not ideal, I know.

from cgofuse.

Updated documentation to better reflect Init() and Destroy():

// FileSystemInterface is the interface that a user mode interface must implement.
//
// The file system will receive an Init() call when the file system is created;
// the Init() call will happen prior to receiving any other file system calls.
// Note that there are no guarantees on the exact timing of when Init() is called.
// For example, it cannot be assumed that the file system is mounted at the time
// the Init() call is received.
//
// The file system will receive a Destroy() call when the file system is destroyed;
// the Destroy() call will always be the last call to be received by the file system.
// Note that depending on how the file system is terminated the file system may not
// receive the Destroy() call. For example, it will not receive the Destroy() call
// if the file system process is forcibly killed.
//
// Except for Init() and Destroy() all file system operations must return 0 on success
// or a FUSE error on failure. To return an error return the NEGATIVE value of a
// particular error.  For example, to report "file not found" return -fuse.ENOENT.

from cgofuse.

+1 for the docs change.

I've worked around this issue in rclone by waiting for the mount directory to appear in Windows before declaring the fs mounted which seems to work OK.

This was only really a problem in the tests anyway.

from cgofuse.