A duplicate file would be the same size/modification time.
To me this suggests that if I had a 10kB file called, say, "A1 Response" in subfolder "A1" and exactly the same file in subfolder "Submitted Assignments", rclone would refuse to download both of them??
I am desperately short of time to back up a 200GB Google Drive that my university will delete due to a change in policy (from "unlimited in perpetuity for free" to, well, not), and I have an extremely nested Google Drive where I often have the same file in multiple different subfolders. This was a very deliberate, and time consuming, archival strategy, so if rclone does download (via copy) only one of the "A1 Response" files, it's going to be a problem for me.
I did a little test where I created a two new subfolders and put the same image in them both, uploaded one at a time, and then told rclone to copy the subfolder and the result was that I got both (identical) files... which is what I want. However, I go back to that earlier question and I think "did I get both files because I couldn't upload the file to each subfolder simultaneously (bad) or because the files were in different folders (good)?"
I guess a part of my question is about how precise the judgement of time is. When I uploaded everything to the Google Drive in the first place I sort of did it en masse... arranging everything in File Explorer and then dragging and dropping the folders. In principle, then, the same file in different subfolders could've been uploaded within the same minute or second as each other. I also tested this by putting my arbitrary image in "Submain 1" and "Submain 2" and then putting those folders in "Main" and uploading it to a Test folder in the Google Drive. I then used rclone to download Test, where I again successfully had both/all four (identical) image files.
There is a bit of context as it needs all the rest to make sense as Google Drives allow for duplicate files in the same folder which a normal OS / mount generally does not.
if that is correct, then, my advice, sooner than later run something like rclone sync gddrive: /path/to/dest --retries=1 --log-level=DEBUG --log-file=/path/to/log.txt
if there are no duplicate files in the same dir, then the rclone sync should work the first time.
if there are a some duplicates to deal with, that would be in the log file.
Okay so just to make sure I understand you and the other things I've read, you're saying that you're only referring to duplicated files within the same folder, e.g. your two testsheet files?
And, per other places, if I have this problem then this is why and when I would want to run dedupe, right?
you stated your goal is to "desperately short of time to back up"
only rclone sync can be trusted for backups.
should not try to use rclone copy for backups.
i could offer some long-winded examples and edge cases, to prove that.
but given the small amount of data, your hard limit on time and that this is your first post in the forum,
be safe, using rclone sync for backups, and
as mentioned up above, test first using --dry-run
no, i am not saying that. rclone copy will not leave files behind.
if the dest is empty and run rclone copy, the dest will an exact mirror/backup the sync
if the dest is NOT empty and run rclone copy, then that strategy is no longer valid
for example, if you delete/move a source file, then rclone copy will not delete the corresponding dest file.
