Are fuse_mount and fuse3_mount blocking?

[overheadhunter]

When not relying on fuse_main, the typical initialization sequence looks like this (there are slight differences between fuse 2 and fuse 3 API, of course):

  fuse = fuse_new(&args, op, op_size, user_data);
  se = fuse_get_session(fuse);
  fuse_set_signal_handlers(se);
  fuse_mount(se, mountpoint);
  fuse_daemonize(fg);
   if (mt)
      fuse_loop_mt(fuse);
  else
      fuse_loop(fuse);
  fuse_remove_signal_handlers(se);
  fuse_unmount(se);
  fuse_destroy(fuse);

We noticed some timing-related issues with WinFSP right after fuse_mount, though: When this method returns, the volume doesn't seem to be ready in all cases.

Therefore, I'd like to ask, whether fuse_mount has a blocking implementation in WinFSP? If the successful invocation isn't intended to be used as a reliable indicator of whether mounting succeeded, what would be the alternative? Is fuse_operations.init reliably called as soon as the file system is mounted?

[billziss-gh]

Your observation re: fuse_mount is correct. The mountpoint is not ready when this function returns. The mountpoint is created within the fuse_loop (or fuse_loop_mt) functions.

Although I do not remember the full reasons for this, I believe this was necessary because of the differences between the UNIX and Windows mounting approaches.

Looking at the code I realize that there is no reliable indicator that the file system mount point has been created in WinFsp-FUSE. This is because the init call also happens before the actual (in-kernel) file system is created (some of the information gathered by init and subsequent statfs calls, etc. is used to initialize the in-kernel file system).

• init
• in-kernel file system creation
• file system mountpoint creation

Can you perhaps describe the reason that you need to know when the in-kernel file system and/or mount point is created (these are two separate events on Windows)? Perhaps I can suggest an alternative solution to the problem.

[overheadhunter]

Can you perhaps describe the reason that you need to know when the in-kernel file system and/or mount point is created (these are two separate events on Windows)? Perhaps I can suggest an alternative solution to the problem.

Sure: The issue occurred during integration tests (but I believe the same is applicable outside the labs as well), where the test setup mounts the file system and then the actual I/O tests start immediately. As you can see in the linked lines, we've added an ugly sleep(100) workaround for now, but as you can imagine this might not be reliable.

So to rephrase the question: When do we know, we can start accessing the mounted volume?

[billziss-gh]

So to rephrase the question: When do we know, we can start accessing the mounted volume?

Unfortunately there is no direct way to know.

One indirect way would be to sleep a bit (say 500ms) then try to access the new drive (e.g. by opening the "volume" using the syntax \\.\X: as detailed in the CreateFileW documentation). If that succeeds then the drive is up and running, if not sleep another 500ms and try again, etc.

[overheadhunter]

Allright, thanks for the clarification!