CODEWITHSUNDEEP
cfuse
atx
atx

Reputation: 5079

FUSE filesystem manipulation

How do I loop over the inodes in the superblock of a FUSE filesystem? The documentation specifies nothing about this.

Upvotes: 2

Views: 2900

Answers (2)

Matt Joiner
Matt Joiner

Reputation: 118660

You can iterate over the visible ones (those with entries), by calling nftw() at the mount point of an active FUSE instance. The callback you provide will be given the path and struct stat for each entry in the filesystem. You can interact with the corresponding inodes via systems calls to the returned paths.

Upvotes: 4

Clarus
Clarus

Reputation: 2338

FUSE is not a file system, and does not contain traditional inodes. It is better to think of it as implementing the reverse of what the UNIX file system API provides. For instance, when you open a file, you generate a file open system call. The kernel then takes that system call and returns a file.

What FUSE does is from the kernel it redirects that system call to the FUSE application which is back in user space. The application then decides how to respond to that system call and returns something to the kernel. The kernel then passes that response back to the original calling application.

In many cases, when you mount something with FUSE, you are not mounting a physical medium. When you open a file in a FUSE file system, it is probably going to create a temporary file on a real file system somewhere, copy data to that file, and then redirect most file operation calls on the FUSE file to the temporary file it created.

Most FUSE application implement stat, and provide most of the information that a real INODE structure would have, however, that information would not in general have a pointer aspect to it.

From a technical standpoint, you could implement something like EXT3 in FUSE, where it would take as a mount argument the EXT3 file system to mount. In that case, you could imagine real INODES, potentially with actual INODE pointers. However, that implementation of EXT3 would probably be fairly unpopular as every file system call would involve going from userspace to kernel to FUSE userspace to kernel to FUSE userspace to kernel and then finally back to your application. FUSE makes a lot more sense for file systems where performance is not important.

Upvotes: 4

Related Questions