commit 7bafb2fd590c5e1b2ebf342df0c431ff4ca6b74c
from: Omar Polo <op@omarpolo.com>
date: Sun Aug 28 10:07:02 2022 UTC

ftp: issue slightly smaller requests to please u9fs

u9fs like to return "i/o count too large" on reads/writes that exceeds
msize - 24.  seems arbiratry, as in theory we should be able to issue a
Tread/Twrite for msize - (HEADERSIZE + 4) = msize - 13.  Don't know
where the other eleven bits come from.

To conclude the rant: even if a client issues a Tread/write too large,
why don't just return a value smaller than requested?  It's explicitly
documented in the plan9 manpage for Tread.

commit - e22049ccccf16f61c96360a85afc0d0a0ef1085f
commit + 7bafb2fd590c5e1b2ebf342df0c431ff4ca6b74c
blob - 141d4d4d85a59fd7edafe9de79c393661980e9db
blob + c45a5cb11b0b375cb1f32e4716c74b48d44058fa
--- kamiftp/ftp.c
+++ kamiftp/ftp.c
@@ -707,7 +707,7 @@ fetch_fid(int fid, int fd, const char *name)
 		ssize_t nw;
 
 		len = MIN(sizeof(buf), msize);
-		len -= HEADERSIZE + 4; /* for the request' fields */
+		len -= IOHDRSZ; /* for the request' fields */
 
 		r = do_read(fid, p.done, len, buf);
 		if (r == 0)
@@ -1304,7 +1304,7 @@ cmd_ls(int argc, const char **argv)
 	evbuffer_drain(dirbuf, EVBUFFER_LENGTH(dirbuf));
 
 	for (;;) {
-		tread(nfid, off, msize - 4);
+		tread(nfid, off, msize - IOHDRSZ);
 		do_send();
 		recv_msg();
 		expect2(Rread, iota_tag);
blob - 96358ea9cb7c08c8a5b9f018d03ef8c7a23cdbc1
blob + 7fb1e1631419ad1d8f1efab4f08f4b3b0c2c2d53
--- lib/kami.h
+++ lib/kami.h
@@ -64,6 +64,13 @@ struct np_stat {
 #define QIDSIZE		13
 #define MAXWELEM	16
 
+/*
+ * from u9fs "ample room for Twrite/Rread header".  It's a bit sloppy
+ * but otherwise it fails with "i/o count too large".  Only for usage in
+ * clients.
+ */
+#define IOHDRSZ		24
+
 #define NPSTATSIZ(namlen, uidnam, gidnam, unam) \
 	(6 + QIDSIZE + 20 + 2 + namlen + 2 + uidnam + 2 + gidnam + 2 + unam)