macos-fuse-t / fuse-t

Other
808 stars 3 forks source link

Race condition between mount exit and filesystem actually being mounted #29

Closed slonopotamus closed 12 months ago

slonopotamus commented 1 year ago

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:

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

I haven't tried with other FUSE filesystems, but highly suspect that they will exhibit the same behaviour.

I first reported this issue to bindfs (https://github.com/mpartel/bindfs/issues/131), but their devs believe (https://github.com/mpartel/bindfs/issues/131#issuecomment-1627819468) the root of the issue lies on fuse-t side.

This issue does NOT reproduce if macFUSE 4.5.0 is used instead of fuse-t 1.0.23.

alexfs commented 1 year ago

Thanks for the report, I will check

slonopotamus commented 12 months ago

Confirming this is fixed in 1.0.24. Thanks!