From: Goswin v. B. <gos...@we...> - 2011-12-21 14:25:49
|
Miklos Szeredi <mi...@sz...> writes: > Stefan Westerfeld <st...@sp...> writes: > >> Hi! >> >> I'd like to implement >> >> myfusefs bar # mount 1 >> fusermount -u bar # unmount 1 >> myfusefs bar # mount 2 >> >> so that my FuSE filesystem runs initialization code first, cleans up during the >> unmount and runs initialization code again. So I'd like to be sure that before >> "mount 2", the old FuSE filesystem cleanup code is done. >> >> Otherwise the initialization and cleanup of "unmount 1" and "mount 2" will >> probably not work, because they are operating on the same data. >> >> Is there a way to ensure that fusermount -u ... blocks long enough so that my >> cleanup code will be completely executed by the time the user can >> remount? > > Not really. > > But you can use a lock file (e.g. lockf(3)) to prevent two instances of > the filesystem running at the same time. What about filesystems of type fuseblk, where you have a real device and tell fuse about it? Does fuse or the kernel do adequate locking on the device for you? >> Also, do I assume correctly that for starting a FuSE filesystem, if I put my >> init code into the fuse_init function, "mount 1/2" will block long enough so >> that after the process exits, the filesystem will be properly initialized, >> right? > > No, the init function is called after the filesystem daemon is already > in the background. > > But you can and should put part of the initialization that can normally > fail into your main() function instead of into the init callback. > > Thanks, > Miklos What about umount? destroy() has no reply so the umount can't wait on that? What does it wait on? MfG Goswin |