For each message, first the struct sent by the kernel is given,
followed by a description of the semantics of the message.
.TP
-.BR FUSE_INIT " ( 25 )"
+.BR FUSE_INIT
.in +4n
.nf
of the minor versions provided by the daemon and the kernel and
both parties should use the protocol corresponding to said minor version.
.TP
-.BR FUSE_GETATTR " ( 3 )"
+.BR FUSE_GETATTR
.\" FIXME It looks like this is for implementing a stat(2) type of
.\" operation. There needs to be a sentence here describing what
.\" this option does.
For the interpretation of these fields, see
.BR stat (2).
.TP
-.BR FUSE_ACCESS " ( 34 )"
+.BR FUSE_ACCESS
.in +4n
.nf
.\" FIXME What does "such field" mean? The 'error' field?
.BR \-EACCES ).
.TP
-.BR FUSE_OPEN " ( 14 ) and " FUSE_OPENDIR " ( 34 )"
+.BR FUSE_OPEN " and " FUSE_OPENDIR
.in +4n
.nf
struct fuse_open_in {
The file is not seekable.
.RE
.TP
-.BR FUSE_READ " ( 15 ) and " FUSE_READDIR " ( 28 )"
+.BR FUSE_READ " and " FUSE_READDIR
.in +4n
.nf
The bytes should be returned directly following the out header,
with no further special out structure.
.TP
-.BR FUSE_INTERRUPT " ( 36 )"
+.BR FUSE_INTERRUPT
.in +4n
.nf
struct fuse_interrupt_in {
After issuing said operation,
the kernel will wait uninterruptibly for completion of the indicated request.
.TP
-.BR FUSE_LOOKUP " ( 1 )"
+.BR FUSE_LOOKUP
Directly following the header is a filename to be looked up in the directory
indicated by
.IR header\->nodeid .
is as for
.BR FUSE_GETATTR .
.TP
-.BR FUSE_FLUSH " ( 36 )"
+.BR FUSE_FLUSH
.in +4n
.nf
struct fuse_flush_in {
However, an empty reply message
still needs to be issued once the flush operation is complete.
.TP
-.BR FUSE_RELEASE " ( 18 ) and " FUSE_RELEASEDIR " ( 29 )"
+.BR FUSE_RELEASE " and " FUSE_RELEASEDIR
.in +4n
.nf
struct fuse_release_in {
but a reply still needs to be issued once the request has
been completely processed.
.TP
-.BR FUSE_STATFS " ( 17 )"
+.BR FUSE_STATFS
This operation implements
.BR statfs (2)
for this filesystem.