There is a way around it. Have HASH return a timestamp as well as the HASH. And another command that checks if the server has executed any command that could have changed the hash. Let's call it CHSH (changed hash) that takes that timestamp as well as a filename and returns either "true", "false" or "unknown" (quoted).Hmm, is it insurmountable or is there a way around it?botg wrote:Actually, forget my proposal, there's something wrong with it. Interacts funnily with the MFMT command.
Example 1: using two FTP connections:
1> HASH foo.txt
<1 213 20091020214634 69d9e6b36078aa77aa2e8e93f88fdf6ce9dc7782
1> CHSH 20091020214634 foo.txt
<1 Validity of hash calculated at 20091020214634 is "true"
Example 2 using two FTP connections:
1> HASH foo.txt
<1 213 20091020214634 69d9e6b36078aa77aa2e8e93f88fdf6ce9dc7782
2> STOR foo.txt (simplified command sequence for the purpose of example)
<2 200 OK
2> MFMT 20091020214634 foo.txt
<2 200 OK
1> CHSH 20091020214634 foo.txt
<1 Validity of hash calculated at 20091020214634 is "false"
Example 3:
1> CHSH 198091020214634 justsomerandomfilename.txt
<1 Validity of hash calculated at 198091020214634 is "unknown"
A server should at least track the changes made to the last file HASH was called on, for each connection. If resources permit, server may keep track of modifications for a longer time. Likewise, servers may cache hashes to improve performance if they keep track of changes to those files.
Now, those specifications aside, I can't but ask myself: Why? There's already FTP over TLS. Files are inherently protected from being corrupted during transfer, with the exception being bugs in either the server or the client. A hash command wouldn't really change this, bugs could still cause it to report success and matching hashes when in fact the file hasn't been written correctly.