Race condition between `bindfs` exit and filesystem actually being mounted

[slonopotamus]

Way to reproduce:

mkdir aa
mkdir bb
bindfs aa bb && umount bb

There's a very high chance that you'll get umount: bb: not currently mounted

Another way to reproduce, more realistic (this is what I actually hit - trying to access files right after mounting them):

mkdir aa
touch aa/file
mkdir bb
bindfs aa bb && ls bb/file

There's a very high chance that you'll get ls: bb/file: No such file or directory

Is there any way to guarantee that by the time bindfs returns non-zero exit code filesystem is actually mounted?

My environment:

• macOS Ventura on M1
• bindfs 1.17.3
• fuse-t 1.0.23

Adding sleep 1 after bindfs exit workarounds the issue, but doesn't look like a proper fix.

[mpartel]

This is almost certainly a fuse-t issue. Bindfs hands over to the FUSE library (provided by fuse-t in this case) here, and the FUSE library handles backgrounding the process.

I can't think of a reasonable workaround to implement in bindfs. As a tedious workaround in your scripts, you might be able to poll the system's list of mounts (not sure where it is on MacOS), though it might appear too early there as well.

Closing this, but feel free to reopen if you think I'm wrong.

[slonopotamus]

No problem, I'll open a similar bug report in fuse-t. From a user PoV, it is pretty hard to understand which part of the system is causing the issue)

[slonopotamus]

Reported to fuse-t: https://github.com/macos-fuse-t/fuse-t/issues/29

[mpartel]

Thanks!

From a user PoV, it is pretty hard to understand which part of the system is causing the issue)

True, and this is the logical place to ask first. Sorry if I came across as implying otherwise.

[slonopotamus]

BTW, confirming that this issue does NOT reproduce with macFUSE 4.5.0, that hints that it is fuse-t to blame.