READ(9P)
π¦ 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 ππ
π¦ where this page comes from
- alpine 3.24: plan9port-doc 0_git20260208-r0 Β· LPL-1.02
- arch rolling: plan9port 20261021-2 Β· custom
- nixos 26.05: plan9port 0-unstable-2025-11-10
- nixos 26.05: plan9port-wayland 0-unstable-2025-11-26
- nixpkgs unstable: plan9port 0-unstable-2025-11-10
- nixpkgs unstable: plan9port-wayland 0-unstable-2025-11-26
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms