From: Miklos S. <mi...@sz...> - 2007-09-18 14:47:43
|
> I am using fuse-2.6.5 and running in the multi-threaded mode. I start > my filesytem by calling fuse_main() which is defined in fuse.h to > "return 0 on success, nonzero on failure". In debug mode (-d on > command line), if a user calls "fusermount -u <mountpoint>" from the > command line to unmount the file system, fuse_main() returns 1. > > First, some philosophical questions. Should an exit due to > user-initiated unmount really be considered a failure? What is the > rationale behind this? > > Second, some practical matters. The return code for fuse_main() > /fuse_main_real()/fuse_main_common() comes from > fuse_kern_chan_receive() and corresponds to the return code of the > read() system call that reads from the channel FD. Function > fuse_kern_chan_receive() returns 0 if it discovers that the session > has exited, -errno if read() returns and error, and the number of > bytes read if read() succeeds. In particular, if the file system is > unmounted, fuse_kern_chan_receive() returns -ENODEV. The comments in > fuse_kern_chan_receive() indicate that three error codes (EINTR, > EAGAIN, and ENODEV) are not actually errors in the Fuse context (and > the printing of the error code message is skipped). The status code > from fuse_kern_chan_receive() propagates up the call stack to > fuse_do_work(). A non-positive status code causes fuse_do_work() to > break from its loop. A negative status code also sets the mt->error > flag. Here, unlike in fuse_kern_chan_receive(), all error codes are > taken to signal an error. The mt->error flag is eventually used as > the return code from fuse_loop_mt() and fuse_main(). > > Why are error codes EINTR, EAGAIN, and ENODEV treated as 'ok' in > fuse_kern_chan_receive() but not in fuse_do_work()? > > If this is an oversight, the patch (against 2.6.5) copied below fixes > the issue. With this patch, when a file system is unmounted, the Fuse > library exits with a zero status. This should already be fixed in 2.7.0. Thanks, Miklos |