Closed slonopotamus closed 12 months 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
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
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?
bindfs
My environment:
Adding sleep 1 after bindfs exit workarounds the issue, but doesn't look like a proper fix.
sleep 1
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.
Thanks for the report, I will check
Confirming this is fixed in 1.0.24. Thanks!
Way to reproduce:
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):
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
afterbindfs
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.