Consistency in case of ZeroFS crashes

[tve]

I'm rcloning ~300MB of media files into a ZeroFS filesystem and I've hit a number of ZeroFS crashes (discussed in several issues). I've re-run rclone and it shows nothing to do; rclone checks the file size and modification times. But I've also run md5sum over all files and I do see discrepancies. The sizes and modification times of the affected files are identical but the contents evidently isn't. I surmise that these files must have gotten corrupt as an effect of one of the ZeroFS crashes? This leads me to the following questions:

• if ZeroFS errors out due to an excess of timeouts/errors from the cloud back-end is it supposed to guarantee "consistency" after it is relaunched and can perform recovery? By consistency I mean that the operations for which it returned success to clients are in fact properly reflected in the filesystem.
• if ZeroFS crashes due to an internal error, what is the consistency guarantee?

EDIT: it actually doesn't look like rclone uses a temp file with rename when the back-end is SFTP, hmmm. I think the questions are still of value, though.

[Barre]

if ZeroFS errors out due to an excess of timeouts/errors from the cloud back-end is it supposed to guarantee "consistency" after it is relaunched and can perform recovery? By consistency I mean that the operations for which it returned success to clients are in fact properly reflected in the filesystem.

Yes and no, operations before fsync yes, operations after fsync, maybe.

if ZeroFS crashes due to an internal error, what is the consistency guarantee?

It should be the same as a classic filesystem, fsync guarantees consistency (and for ZeroFS, a single fsync guarantees that the full system is synced), there's no guarantees for operations that are not fsynced.