This was generated on 2005/09/27 from http://fuse.sourceforge.net/wiki/index.php/FAQ For an up to date version please see the above page. You can also add new entries there. General ======= How can I umount a filesystem ----------------------------- Filesystems mounted without sysadmin privileges can be umounted with the command fusermount -u mountpoint What's the difference between FUSE and LUFS? -------------------------------------------- The main difference between them is that in LUFS the filesystem is a shared object (.so) which is loaded by lufsmount, and in FUSE the filesystem is a separate executable, which uses the fuse library. The actual API is very similar, and there's a translator, that can load LUFS modules and run them using the FUSE kernel module (see the lufis package on the FUSE page). Another difference is that LUFS does some caching of directories and file attributes. FUSE does not do this, so it provides a 'thinner' interface. By now LUFS development seems to have completely ceased. Why is it called FUSE? There's a ZX Spectrum emulator called Fuse too. ---------------------------------------------------------------------- At the time of christening it, the author of FUSE (the filesystem) hadn't heard of Fuse (the Speccy emulator). Which is ironic, since he knew Philip Kendall, the author of that other Fuse from earlier times. Btw. the author of FUSE (the filesystem) also created a Speccy emulator called Spectemu. The name wanted to be a clever acronym for "Filesystem in USErspace", but it turned out to be an unfortunate choice. The author has since vowed never to name a project after a common term, not even anything found more than a handful of times on Google. API === Which method is called on the close() system call? -------------------------------------------------- flush() and possibly release(). For details see the documentation of these methods in Wouldn't it be simpler if there were a single close() method? ------------------------------------------------------------- No, because the relationship between the close() system call and the release of the file (the opposite of open) is not as simple as people tend to imagine. UNIX allows open files to acquire multiple references * after fork() two processes refer to the same open file * dup() and dup2() make another file descriptor refer to the same file * mmap() makes a memory mapping refer to an open file This means, that for a single open() system call, there could be more than one close() and possibly munmap() calls until the open file is finally released. Can I return an error from release()? ------------------------------------- No, it's not possible. If you need to return errors on close, you must do that from flush(). How do I know which is the last flush() before release()? --------------------------------------------------------- You can't. All flush() calls should be treated equally. Anyway it wouldn't be worth optimizing away non-final flushes, since it's fairly rare to have multiple write-flush sequences on an open file. Why doesn't FUSE forward ioctl() calls to the filesystem? --------------------------------------------------------- Because it's not possible: data passed to ioctl() doesn't have a well defined length and structure like read() and write(). Consider using getxattr() and setxattr() instead. Is there a way to know the uid, gid or pid of the process performing -------------------------------------------------------------------- the operation? -------------- Yes: fuse_get_context()->uid, etc. Problems ======== Why are some bytes zeroed when reading a file? ---------------------------------------------- This happens if the filesystem returns a short count from the read() method. If the file wasn't opened in direct I/O mode, the read() method must return exactly the requested number of bytes, unless it's the end of the file. If the file was opened in direct I/O mode (with direct_io mount option, or by setting the direct_io field of fuse_file_info at open) the read can return a smaller value than requested. In this case the end of file can be signalled by returning zero. Why doesn't find work on my filesystem? --------------------------------------- The st_nlink member must be set correctly for directories to make find work. If it's not set correctly the -noleaf option of find can be used to make it ignore the hard link count (see man find). The correct value of st_nlink for directories is NSUB + 2. Where NSUB is the number of subdirectories. NOTE: regular-file/symlink/etc entries do not count into NSUB, only directories. If calculating NSUB is hard, the filesystem can set st_nlink of directories to 1, and find will still work. This is not documented behavior of find, and it's not clear whether this is intended or just by accident. But for example the NTFS filesysem relies on this, so it's unlikely that this "feature" will go away. What is the reason for IO errors? --------------------------------- The kernel part of FUSE returns the EIO error value, whenever the userspace filesystem sends a "bad" reply. Sometimes these are unavoidable, and not necessarily a fault of the filesystem. Possible causes of this are (non-exhaustive) * the filesystem returned a short count on write() * the type of the file has changed (e.g. a directory suddenly became a symlink) * a directory entry contained a filename that was too long (no, ENAMETOOLONG is not the right error here) * the same node ID value was used for two different directories (i.e. hard-linked directories are not allowed) Misc ==== Can the filesystem ask a question on the terminal of the user? -------------------------------------------------------------- It would not be possible generally speaking, since it might not be an interactive program but rather a daemon, or a GUI program doing the operation. However you should be able to get the PID for the caller, and by looking in /proc you should be able to find the process tty or something similar. But this is not recommended. You should rather think about solving this another way.