Oh, that’s odd. It works for me at least. Can you describe what you did? Did you take the backup on Windows and restored on Windows and Linux?
Can you check with restic cat snapshot <id> and restic cat blob <id> what the metadata stored in the repo says? Are there timestamps recorded?
Can you please try to reproduce the issue by saving a directory with a single text file, then share the repository with me? That’d be great so I can dig into the issue…
ctime is tricky, because on Linux it’s “change time” while on Windows it’s “created time”, and on Linux a user program cannot modify ctime.
AFAIK, Go doesn’t have a Windows-specific built-in function to change “created time”.
I confirm that restic restore (completed) does indeed not write the original’s “created:” of the file. I think this behavior is expected since you are in reality creating a copy of the original file. I see the same behavior on a commercial Veeam Enterprise backup where if I restore a single file using “copy…” and not in place restore, the “Created:” date is today… This behavior is seen also under linux where restic restore creates a new copy of the file at the target (-t). Finding the “Created:” date is complicated (with inodes and debugfs) but consequent with the behavior you see in windows.
Now if I use an in place restore from Veeam (overwriting the original file), I see correct date for create date. But in reality, in 25+ year in IT, I never done that. ALWAYS do my restore elsewhere, there integrate back restored file by explorer copy. All these steps leads to “Created:” being recent.
To this regard, I think restic is doing just fine.
One other thing I discovered today that seems to be related, during the restore on Windows files are initially created with the current modified datestamp, and only later does restic update the restore.
This bit me with a restore operation that was restoring data into a live directory while another tool was indexing, at the end of the restoration process it happily deleted the entire index and started over as the datestamps changed.
Not a big deal, just not what I had expected or I would have stopped the indexing first.
File restore isn’t atomic, so the indexing tool will see partially restored files. Restic could restore files under temporary directory/name first, then move the fully restored files into their target directories… but then the indexing tool would see the temporary files. Disabling indexing during restore seems like the easiest way to avoid unnecessary reindexing.
That was a known risk, I was only indexing files moved in subdirectories, and once the file existed more than 30 seconds. In my case the goal was to get things indexes as fast as possible, so it made sense to be scanning the live content.
Normally I’m more patient.
But I felt it was worth mentioning because I hit this thread wondering why time stamps weren’t being restored, confirmed my expectation that they should be, and only later did all the time stamps update — This was more to help anyone in the future who is looking for the same.
