First, kudos to @beebmaster for hard work confirming what i’ve found…
On OSWORD &14 arg 0 (do fileserver operation),the client machine sets a byte in tge tx block to indicate its length so NFS sends the right number of bytes.
On return after a successful query, buf?1 is defined as the reply length.
Except it’s not. Neither NFS nir ANFS changes it from the tx length. So the client cannot reliably tell how much data was received.
Perhaps this is why the FS spec always has some sort of terminator in fs replies which are not a guaranteed fixed length - eg &0D or &80….
How did this go unnoticed for 40+ years??!
Best
C
PS this came up while testing some PiFS-specific Fileserver operations (eg filename canonicalization, bridge build information, bridge config, etc…)
On OSWORD &14 arg 0 (do fileserver operation),the client machine sets a byte in tge tx block to indicate its length so NFS sends the right number of bytes.
On return after a successful query, buf?1 is defined as the reply length.
Except it’s not. Neither NFS nir ANFS changes it from the tx length. So the client cannot reliably tell how much data was received.
Perhaps this is why the FS spec always has some sort of terminator in fs replies which are not a guaranteed fixed length - eg &0D or &80….
How did this go unnoticed for 40+ years??!
Best
C
PS this came up while testing some PiFS-specific Fileserver operations (eg filename canonicalization, bridge build information, bridge config, etc…)
Statistics: Posted by cr12925 — Thu Jun 20, 2024 9:21 pm