And I just now realized that while all the files on B: have the correct date modified (many years ago).
Every single folder on B: has today as the date modified.... Is there a flag that would've preserved this metadata? Because simply using windows command line copy A: B: would've preserved that metadata
I notice there are several general flags that attempt to control date modified, but they seem to mostly be designed to target remote google drive not another HDD?
The modified date and the creation date are BOTH today. Nothing about the original date in anyway was preserved. Okay so, creation date wasn't supposed to be saved, fine. I too usually use modified date.
In this example the modified date for all files is correct and the modified date for all folders is today (instead of years ago).
If rclone is supposed to save the modified date, how do I make it do so?
I WANT the files to be getting the modification date set as their creation date. It is working, for files. It is not working for folders.
So the issue is one of folders, and has nothing to do with creation dates. I only care about the modification date being preserved. It is doing this correctly for files. It is not doing it for folders. I'm wondering if there is a flag that helps with this. As I've seen several date related flags on the general flag list.
I fear though that rclone simply doesn't care about folders at all, and that the function I want doesn't exist. In which case I should wipe the new drive clean again and do a normal clone and then if I want to use rclone to check it's md5's rather than just having rcloned it in the first place.
I'll give fastcopy a try, yeah, robocopy was kinda scaring me a bit.
Although what I've done in this case, is the most insanely bad idea ever, I'm just copy pasting in windows file explorer :-/ which is probably horrendeously dumb
ugh even fastcopy was only 90% correct for root directories and 100% correct for other directories!!! no clue how to make every single directory correct other than something like straight up dd, but the new drive partition is larger/different so that's less than ideal too.
I noticed something in the command flag parameters for robocopy.
The functionality that I dislike, in all these programs, is to use DAT default for file attributes and DA default for directory attributes in robocopy.
Which is then trivial to change to DAT and DAT (robocopy by default doesn't transfer timestamps on purpose).
robocopy /e /dcopy:dat "A:" "B:"
plus whatever other options you wish, the key solution to my confusion throughout this entire thread is the /dcopy:dat part
To clarify, I don't expect rclone to become a good local to local option, but I do expect other rclone users to have this same problem, and I want to mark one of the posts in this thread as an answer. Assuming this robocopy command does exactly what I want, I'll mark this.
Also, side note, to anyone reading this as a solution in the distant future:
edit1: okay, he deleted all his posts.... the best tip I got from him though was:
fastcopy is a cool local copying program
freefilesync is also cool
robocopy is scary but can do a lot of things
and he made a wiki to give rclone vss functionality which makes it possible to copy things windows likes to mess with:
his wiki article is good, and might help someone with some rclone copying issues
edit2: note to self, don't give robocopy administrator access, there was a system file from a computer I had back in like 2005 that it fixed access on, aka, took my access away. I think I preferred it when that file simply couldn't be accessed.
edit4: exact command I decided to go with: robocopy /e /dcopy:dat /r:1 /w:2 /np /log:robocopylogfile.log "A:" "B:"
had to create the log file manually before running it, didn't run as administrator, will report back tomorrow I suppose on how "perfect" or "not" things went.