Kristaps Dzonsons <[email protected]> wrote: > >> ... it says the modification time is a time_t. Which means we only > >> have seconds, not subseconds. > > > > Fair enough. The protocol predates common availability of nanosecond > > file timestamps. > > It's worse than that. It's 32-bit time_t.
Your docs say it is a time_t, but the code says it isn't. It is handled as an int. A wire protocol should never use a typedef which could change size. Anyways, I suspect upon send/recv of the value it needs to be treated as unsigned, and upon receive also unsigned extended into 64-bits so that it works beyond 2038. We did this in a pile or places, since it is sensible and realistic that the solution will outlast the specific protocol (or filesystem).
