> I finally got a little annoyed about the fusermount -u behavior and
> looked into it. The problem is that if I mount my filesystem and then
> later use fusermount -u to unmount it, sometimes it would unmount the
> filesystem but wouldn't remove the fuse entry from /etc/mtab. [Note
> that in version 1.0 release it will corrupt my /etc/mtab -- I had an
> early fix that made it into the CVS only after that release].
> The problem seems to be that when the filesystem gets notified that it
> is being unmounted, it arranges for fusermount to unmount the system, so
> there is a race condition where two fusermount programs are running
> trying to do the same work.
> I'm not sure that either can be eliminated, since they can handle
> different cases, but they do need some sort of synchronization.
> Attached is a proposed patch which adds an empty /etc/mtab.fuselock
> file which is used for locking to stop multiple fusermount instances
> from modifying mtab at once. I have also uploaded it to the patches
Applied to CVS with a little cleanup.
On Thu, 2003-12-11 at 06:26, Miklos Szeredi wrote:
> > Attached is a proposed patch which adds an empty /etc/mtab.fuselock
> > file which is used for locking to stop multiple fusermount instances
> > from modifying mtab at once. I have also uploaded it to the patches
> > section.
> Applied to CVS with a little cleanup.
Aha, I forgot to follow the coding convention in FUSE :-)
Thanks for cleaning up my patch -- it was clumsy for production code.
However, I think you may have introduced a minor error in the change to
lock_mtab: perror() is being passed a string containing "%s", but it is
not a printf style variable arg function..