Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 1 | This was generated on 2005/09/27 from |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 2 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 3 | http://fuse.sourceforge.net/wiki/index.php/FAQ |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 4 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 5 | For an up to date version please see the above page. You can also add |
| 6 | new entries there. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 7 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 8 | General |
| 9 | ======= |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 10 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 11 | How can I umount a filesystem |
| 12 | ----------------------------- |
| 13 | |
| 14 | Filesystems mounted without sysadmin privileges can be umounted with |
| 15 | the command |
| 16 | |
| 17 | fusermount -u mountpoint |
| 18 | |
| 19 | What's the difference between FUSE and LUFS? |
| 20 | -------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 21 | |
| 22 | The main difference between them is that in LUFS the filesystem is a |
| 23 | shared object (.so) which is loaded by lufsmount, and in FUSE the |
| 24 | filesystem is a separate executable, which uses the fuse library. The |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 25 | actual API is very similar, and there's a translator, that can load |
| 26 | LUFS modules and run them using the FUSE kernel module (see the lufis |
| 27 | package on the FUSE page). |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 28 | |
| 29 | Another difference is that LUFS does some caching of directories and |
| 30 | file attributes. FUSE does not do this, so it provides a 'thinner' |
| 31 | interface. |
| 32 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 33 | By now LUFS development seems to have completely ceased. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 34 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 35 | Why is it called FUSE? There's a ZX Spectrum emulator called Fuse too. |
| 36 | ---------------------------------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 37 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 38 | At the time of christening it, the author of FUSE (the filesystem) |
| 39 | hadn't heard of Fuse (the Speccy emulator). Which is ironic, since he |
| 40 | knew Philip Kendall, the author of that other Fuse from earlier times. |
| 41 | Btw. the author of FUSE (the filesystem) also created a Speccy |
| 42 | emulator called Spectemu. |
Miklos Szeredi | e518374 | 2005-02-02 11:14:04 +0000 | [diff] [blame] | 43 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 44 | The name wanted to be a clever acronym for "Filesystem in USErspace", |
| 45 | but it turned out to be an unfortunate choice. The author has since |
| 46 | vowed never to name a project after a common term, not even anything |
| 47 | found more than a handful of times on Google. |
Miklos Szeredi | e518374 | 2005-02-02 11:14:04 +0000 | [diff] [blame] | 48 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 49 | API |
| 50 | === |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 51 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 52 | Which method is called on the close() system call? |
| 53 | -------------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 54 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 55 | flush() and possibly release(). For details see the documentation of |
| 56 | these methods in <fuse.h> |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 57 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 58 | Wouldn't it be simpler if there were a single close() method? |
| 59 | ------------------------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 60 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 61 | No, because the relationship between the close() system call and the |
| 62 | release of the file (the opposite of open) is not as simple as people |
| 63 | tend to imagine. UNIX allows open files to acquire multiple |
| 64 | references |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 65 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 66 | * after fork() two processes refer to the same open file |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 67 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 68 | * dup() and dup2() make another file descriptor refer to the same |
| 69 | file |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 70 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 71 | * mmap() makes a memory mapping refer to an open file |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 72 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 73 | This means, that for a single open() system call, there could be more |
| 74 | than one close() and possibly munmap() calls until the open file is |
| 75 | finally released. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 76 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 77 | Can I return an error from release()? |
| 78 | ------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 79 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 80 | No, it's not possible. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 81 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 82 | If you need to return errors on close, you must do that from flush(). |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 83 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 84 | How do I know which is the last flush() before release()? |
| 85 | --------------------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 86 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 87 | You can't. All flush() calls should be treated equally. Anyway it |
| 88 | wouldn't be worth optimizing away non-final flushes, since it's fairly |
| 89 | rare to have multiple write-flush sequences on an open file. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 90 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 91 | Why doesn't FUSE forward ioctl() calls to the filesystem? |
| 92 | --------------------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 93 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 94 | Because it's not possible: data passed to ioctl() doesn't have a well |
| 95 | defined length and structure like read() and write(). Consider using |
| 96 | getxattr() and setxattr() instead. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 97 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 98 | Is there a way to know the uid, gid or pid of the process performing |
| 99 | -------------------------------------------------------------------- |
| 100 | the operation? |
| 101 | -------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 102 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 103 | Yes: fuse_get_context()->uid, etc. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 104 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 105 | Problems |
| 106 | ======== |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 107 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 108 | Why are some bytes zeroed when reading a file? |
| 109 | ---------------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 110 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 111 | This happens if the filesystem returns a short count from the read() |
| 112 | method. If the file wasn't opened in direct I/O mode, the read() |
| 113 | method must return exactly the requested number of bytes, unless it's |
| 114 | the end of the file. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 115 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 116 | If the file was opened in direct I/O mode (with direct_io mount |
| 117 | option, or by setting the direct_io field of fuse_file_info at open) |
| 118 | the read can return a smaller value than requested. In this case the |
| 119 | end of file can be signalled by returning zero. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 120 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 121 | Why doesn't find work on my filesystem? |
| 122 | --------------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 123 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 124 | The st_nlink member must be set correctly for directories to make find |
| 125 | work. If it's not set correctly the -noleaf option of find can be |
| 126 | used to make it ignore the hard link count (see man find). |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 127 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 128 | The correct value of st_nlink for directories is NSUB + 2. Where NSUB |
| 129 | is the number of subdirectories. NOTE: regular-file/symlink/etc |
| 130 | entries do not count into NSUB, only directories. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 131 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 132 | If calculating NSUB is hard, the filesystem can set st_nlink of |
| 133 | directories to 1, and find will still work. This is not documented |
Miklos Szeredi | 4322e17 | 2005-08-02 09:53:51 +0000 | [diff] [blame] | 134 | behavior of find, and it's not clear whether this is intended or just |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 135 | by accident. But for example the NTFS filesysem relies on this, so |
| 136 | it's unlikely that this "feature" will go away. |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 137 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 138 | What is the reason for IO errors? |
| 139 | --------------------------------- |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 140 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 141 | The kernel part of FUSE returns the EIO error value, whenever the |
| 142 | userspace filesystem sends a "bad" reply. Sometimes these are |
| 143 | unavoidable, and not necessarily a fault of the filesystem. Possible |
| 144 | causes of this are (non-exhaustive) |
| 145 | |
| 146 | * the filesystem returned a short count on write() |
| 147 | |
| 148 | * the type of the file has changed (e.g. a directory suddenly |
| 149 | became a symlink) |
| 150 | |
| 151 | * a directory entry contained a filename that was too long (no, |
| 152 | ENAMETOOLONG is not the right error here) |
| 153 | |
| 154 | * the same node ID value was used for two different directories |
| 155 | (i.e. hard-linked directories are not allowed) |
| 156 | |
| 157 | Misc |
| 158 | ==== |
| 159 | |
| 160 | Can the filesystem ask a question on the terminal of the user? |
| 161 | -------------------------------------------------------------- |
Miklos Szeredi | e518374 | 2005-02-02 11:14:04 +0000 | [diff] [blame] | 162 | |
Miklos Szeredi | a2c5e56 | 2004-10-19 22:01:21 +0000 | [diff] [blame] | 163 | It would not be possible generally speaking, since it might not be an |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 164 | interactive program but rather a daemon, or a GUI program doing the |
| 165 | operation. However you should be able to get the PID for the caller, |
| 166 | and by looking in /proc you should be able to find the process tty or |
| 167 | something similar. |
Miklos Szeredi | e518374 | 2005-02-02 11:14:04 +0000 | [diff] [blame] | 168 | |
Miklos Szeredi | 4cecc25 | 2005-09-27 15:42:22 +0000 | [diff] [blame] | 169 | But this is not recommended. You should rather think about solving |
| 170 | this another way. |