From: Nikolaus R. <Nik...@ra...> - 2011-09-24 22:31:14
|
Nikolaus Rath <Nik...@pu...> writes: > Miklos Szeredi <mik...@pu...> writes: >> Nikolaus Rath <Nik...@pu...> writes: >> >>> Miklos Szeredi <mik...@pu...> writes: >>>> "Lucas C. Villa Real" <luc...@pu...> writes: >>>> >>>>> For the sake of curiosity, I tried closing the file descriptor >>>>> associated to /dev/fuse on my implementation of getattr(). That caused >>>>> a connection abort error on the client side (as expected), and the >>>>> FUSE file system exited after that. However, further attempts to >>>>> access the mount point succeeded with no errors, which is not what you >>>>> want. >>>> >>>> Right, because after you close the file descriptor libfuse will see an >>>> error when trying to read from the device and so exits cleanly, >>>> unmounting the filesystem along the way. >>>> >>>> The way to prevent unmounting is to skip fuse_unmount() in the cleanup >>>> sequence. >>> >>> No, this does not help. Until the process exits, attempts to access the >>> mountpoint hang rather than being refused. >> >> The fuse device fd needs to be closed. Apparently fuse_unmount() is >> doing it now, so you need to just call fuse_chan_destroy() instead and >> it should work. > > Ah, I see. That works nicely, thanks! Actually there is one small inconsistency: after calling fuse_chan_destroy(), but before the process has terminated, attempts to access the mountpoint give EIO. After the process has terminated, this changes to ESHUTDOWN. Why is that? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |