search

bispawel / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

-o ping_diskarb has initialization race condition #10

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
When I mount a ssh volume it has read/write access, but it shows up with no 
available disk space.

Command used:
mkdir /Volumes/sshdisk
sshfs user@server: /Volumes/sshdisk/ -o ping_diskarb  -o volname=sshDisk

Used the fuse-0.1.0b004.tar.bz2 on a Mac OS X (ppc) 10.4.8 (8L127)

Original issue reported on code.google.com by ty...@apoio.se on 12 Jan 2007 at 1:15

GoogleCodeExporter commented 8 years ago 
This is unfortunately a race condition. More details are at
http://code.google.com/p/macfuse/wiki/MACFUSE_AND_THE_FINDER ; I'm turning this 
into
our tracking bug.

Original comment by motown...@gmail.com on 12 Jan 2007 at 2:08

GoogleCodeExporter commented 8 years ago 
Please try fuse-0.1.0b005 and see if it fixes the issue.

Original comment by si...@gmail.com on 12 Jan 2007 at 7:31

GoogleCodeExporter commented 8 years ago

Original comment by si...@gmail.com on 12 Jan 2007 at 7:32

GoogleCodeExporter commented 8 years ago 
hi,
sorry for the uninformed comment (I haven't looked at the source yet). The wiki 
page mentioned above states 
that:

There is, however, a subtle problem that exists today with MacFUSE and the 
-oping_diskarb flag. If you specify 
-oping_diskarb, MacFUSE will initialize the filesystem, and then, without 
waiting for the reply from the 
filesystem daemon, tell Disk Arbitration that there is a new disk. At this 
point, there's a race condition. As 
soon as the Finder recognizes that there is a new filesystem, it will statfs 
it. But is the filesystem daemon 
ready?

Wouldn't the race condition be fixed by moving the call to disk arbitration 
into the filesystem daemon 
callback?

Original comment by ccmtay...@gmail.com on 13 Jan 2007 at 1:18

GoogleCodeExporter commented 8 years ago 
Actually, my understanding is that this race condition was fixed in 
fuse-0.1.0b005, probably in revision 63.

Original comment by chucker...@gmail.com on 13 Jan 2007 at 1:24

GoogleCodeExporter commented 8 years ago 
Marking fixed assuming people are not seeing this any more.

Original comment by si...@gmail.com on 15 Jan 2007 at 9:34