It does mention hashes, the modime support is non-binary - what is supported is a precision. Very large precisions are effectively ignores so rclone sets them to 100y for backends which don't support precisions.
oh, I see, thanks for the explanation, it wasn't really clear from the docs.
okay, so... bottom line:
interested users can check out the --track-renames and --track-renames-strategy flags. NOTE: those flags rely on either the hash or the modtimes being supported by the remotes.
I did think of doing some other strategies, maybe "leaf" to deal with the very common case of just moving files around rather than renaming the file itself. Would that be useful?
Also rclone could potentially do a "sample" option where it reads the first 1k of the file, makes a hash and uses that.
I'll add my two cents:
why not create a local hash/modtime database?
it would be useful for tracking renames and extending some functionalities for unsupported remotes like Mega.
moreover, folks that are using the crypt remote will be interfacing with their cloud providers only through rclone, and never via web or other methods, so that rclone would be confident that nobody modified the file.
rclone could be set up to periodically hashcheck the files, downloading them if needed, to make sure this local db is updated.
does this make sense?