This is just for discussion to make myself smarter hopefully.
I've been using rclone successfully for a number of years now, but only recently has it become more of an issue to get rclone to be less aggressive with what it sees as a different file in our environment.
My understanding is that rclone* uses file name / file size for determining if a file is the same.
(I could be wrong I revisit rclone once every 6 months and the details get fuzzy and I've not easily found the exact answer to this in the documentation this go around.)
There is a recent scenario where a file was made smaller, and completely recreated (new created date) on the Windows server (outside of my control).
But the name of the file is the same, it's intended be a simple revision, but rclone interpreted it as a new file presumably because of the file size difference (?). rclone trashed the file at the destination and created a new file in its place with the same name.
I've been trying to figure out if it's possible to have it ignore size difference or at the very least better understand the exact behavior for how it decides if a file is the same or not.
In my mind it would work like:
For adds:
If a source file name has a match at destination, replace that with a revision at destination. Maintaining the drive link.
If a source file name does not have a match at destination write new file to destination.
But it seems like it also uses something else, is it possible to control this behavior?
I understand you can use track-renames for tracking renames on source, but what about just making rclone more permissive in what it sees as the same file in general?
I am using the sync operation which looks like --ignore-size is only for the copy command,
I read that it said size/modtime & hash, but I was confused as to if it were possible to specify, which strategy, or hopefully suppress that behavior and rely on leaf/modtime to decide if "edits" (uploads as an in place revision) in drive or deletes it.
Oh. See I was looking at the sync commands page and I misinterpreted that meant it could only be used for copy specifically.
This all helps in a general sense thank you.
However digging into my specific issue a little more.
rclone deleted a file, then a new smaller file was created.
But it looks like the reason for this may have been a case of someone deleting the file in the SRC, rclone synced successfully removing the file, then someone added updated versions of those files to SRC that were caught by another sync.
I unfortunately don't have verbose output for the incident so it's hard to say, but in testing with the commands you've listed, it looks like in any situation where I have: Same Name Different / Size or Hash. It would replace the existing on the remote in Drive, the only time it doesn't, of course, is if it's already been deleted.
Now I just have to figure out how to mitigate that scenario.
Or find a way to capture deletes in their own specific log file for remediation.
Maybe I can untrash the existing file then merge the new file into the one that was trashed in Drive.