Is there a way to make sure rclone preserves the metadata of the "date created" or "date modified" fields?

Help and Support
1

So, I ran:

rclone copy -v "A:" "B:"

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 :frowning:

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?

Would one of those have worked?

3

You've misunderstood the question.

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?

5

Creation date wasn't at all relevant to my question. I shouldn't've included it in my phrasing, since it wasn't important. All I care about is date modified, and it's date modified that isn't working.

7

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.

9

I included the command I used.

rclone copy -v "A:" "B:"

as in local harddrive partition a to local harddrive partition b as in no backend at all, purely local.

In this case windows 10. That probably actually matters and I left that out.

11

Only because I'm so used to rclone I didn't think to use the basic OS tool. I use rclone for like everything (usually involving google drive).

That's a good answer though, just don't use rclone for local to local.

Although I know plenty of people who sync their local data to an external harddrive using rclone to make backups of their data, which is local to local.

12

Rclone should preserve the modification date, even for local -> local copies.

$ rclone lsl z
     4762 2020-06-24 21:59:59.398558174 z
$ rclone copyto z z.copy
$ rclone lsl z.copy
     4762 2020-06-24 21:59:59.398558174 z.copy

Is that not what you see?

13

It preserves the modification date of FILES, but not FOLDERS. It gives the new folders a modification date of whenever you ran the command.

15

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

16

Sorry, you are quite right. Rclone doesn't do a good job of preserving datestamps on folders.

17

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.

19

I think the problem isn't fastcopy's fault, it's gotta be something to do with my system setup.

out of 700,000 items fastcopy only got 333 dates wrong. that's a pretty good rate. is there anyway to manually set dates and times on windows 10? I could just manually fix 333 problems out of 700,000.

21

I don't really agree that it's not an issue for rclone, given that it's something rclone doesn't do, that users might be curious about, but I'll private message you.

23

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).

So, solution:

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:

I didn't understand what was going on at all, until I read this post Is there a way to make sure rclone preserves the metadata of the "date created" or "date modified" fields? which had a lot of really good advice/tips/alternatives

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.

24

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.