Is it possible the Init method is called slightly before the file system is ready?

[ncw]

Is it possible the Init method is called slightly before the file system is ready?

My code is waiting for the Init() method to be called (wait for signal and signal), but I'm finding in the tests that sometimes the mount appears not to be ready then.

Bad

X:\go\src\github.com\ncw\rclone\cmd\cmount>go test -v -run Ls
2017/05/08 16:23:00 mount "Local file system at \\\\?\\C:\\Users\\Dev\\AppData\\
Local\\Temp\\rclone408473623" "E:"
2017/05/08 16:23:00 mount OK
=== RUN   TestDirLs
--- FAIL: TestDirLs (0.00s)
        Error Trace:    fs.go:219
                        fs.go:254
                        dir.go:16
        Error:          Received unexpected error:
                        open E:/: The system cannot find the path specified.
The service cmount.test has been started.  <=============== NB after the test runs
FAIL
2017/05/08 16:23:00 Unmounting "E:"
The service cmount.test has been stopped.
2017/05/08 16:23:00 Waiting for umount
exit status 1
FAIL    github.com/ncw/rclone/cmd/cmount        0.075s

OK

X:\go\src\github.com\ncw\rclone\cmd\cmount>go test -v -run Ls
2017/05/08 16:23:46 mount "Local file system at \\\\?\\C:\\Users\\Dev\\AppData\\
Local\\Temp\\rclone968580219" "E:"
2017/05/08 16:23:46 mount OK
The service cmount.test has been started.  <=============== NB before the test runs
=== RUN   TestDirLs
--- FAIL: TestDirLs (0.00s)
        Error Trace:    fs.go:280
                        dir.go:18
        Error:          Received unexpected error:
                        mkdir E:/a directory: The handle is invalid. <=== I'm debugging this - it is an error in my code!
FAIL
2017/05/08 16:23:47 Unmounting "E:"
The service cmount.test has been stopped.
2017/05/08 16:23:47 Waiting for umount
exit status 1
FAIL    github.com/ncw/rclone/cmd/cmount        1.077s

I can work around this with a small sleep, but it seems not to be working as advertised!

[billziss-gh]

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.

[ncw]

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.

[billziss-gh]

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.

[ncw]

+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.