READ(9P)

πŸ“¦ version 0_git20260208, in alpine 3.24, arch rolling, nixos 26.05, nixpkgs unstable

πŸ¦‹ READ(9P) β€” read, write πŸ¦‹

okay so bestie, welcome to the 9P manual page for read and write πŸ’… this is the one where data gets moved from and to a file, and the vibe is β€œtiny protocol messages, main-character energy” ✨


🌸 NAME 🌸

read, write β€” transfer data from and to a file 🫢


✨ SYNOPSIS ✨

size[4] Tread tag[2] fid[4] offset[8] count[4]
size[4] Rread tag[2] count[4] data[count]

size[4] Twrite tag[2] fid[4] offset[8] count[4] data[count]
size[4] Rwrite tag[2] count[4]

πŸ’– DESCRIPTION πŸ’–

The read request is basically β€œhey bestie, gimme count bytes from the file identified by fid” πŸ‘‘ and that fid must be opened for reading β€” no sneaky read access on a write-only vibe, okay? It starts offset bytes after the beginning of the file, and the bytes come back in the read reply message. Slay.

The count field in the reply says how many bytes actually came back. It may be less than the requested amount β€” not a bug, just the protocol being real. If the offset field is greater than or equal to the number of bytes in the file, you get a count of zero. πŸ’€

For directories, read returns an integral number of directory entries exactly as in stat (see stat(9P)), one for each member of the directory. The read request message must have offset equal to zero or the value of offset in the previous read on the directory, plus the number of bytes returned in the previous read. In other words:

seeking other than to the beginning is illegal in a directory 🚨 bestie do not do it.

The write request asks that count bytes of data be recorded in the file identified by fid, which must be opened for writing, starting offset bytes after the beginning of the file. If the file is append-only, the data will be placed at the end of the file regardless of offset β€” yep, offset gets ignored in that case. Directories may not be written. Periodt. πŸŽ€

The write reply records the number of bytes actually written. It is usually an error if this is not the same as requested. 😭

Because 9P implementations may limit the size of individual messages, more than one message may be produced by a single read or write call. The iounit field returned by open(9P), if non-zero, reports the maximum size that is guaranteed to be transferred atomically. Iconic. πŸ”₯


🧚 ENTRY POINTS 🧚

Fsread and fswrite (see 9pclient(3)) generate the corresponding messages. Because they take an offset parameter, the fspread and fspwrite calls correspond more directly to the 9P messages. Although fsseek affects the offset, it does not generate a message. πŸ’…


πŸ’Œ cute sign-off: source/version vibe is the 9P manual, the footer tag is READ(9P), and there’s no separate date line in this footer β€” mwah, bestie πŸ˜­πŸ’–