Datestamps not restored

I’m doing my first restore in anger under Windows.

As you can see, timestamps are not preserved.

My restore command is::

restic restore -H Athena latest --path="C:\Users\Jnani\Documents" --target=c:\restore -v

I tried using \\?\C\ as mentioned in one issue:

restic restore -H Athena latest  --target "\\?\C:\restore-dates" -vv

But still no datestamps restored.

I then tried restoring on Linux:

stat DSCF2208.JPG
  File: DSCF2208.JPG
  Size: 1342547         Blocks: 2624       IO Block: 4096   regular file
Device: 811h/2065d      Inode: 923         Links: 1
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/    ravi)   Gid: ( 1000/    ravi)
Access: 2019-08-15 14:26:45.718525600 +0700
Modify: 2019-08-15 14:26:45.767208500 +0700
Change: 2019-08-15 14:26:45.767208500 +0700
 Birth: -

All 3 listed times are just now.

Backups and restores were done with version 0.9.5

How do I restore all timestamps on both files and directories?

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…

I cancelled the restore (I had a another method up my sleeve) when I found that timestamps were not being restored…

But then found that on a completed restore that timestamps are indeed set… but not the creation time.

Backup taken and restored on Windows.

Can you confirm that ctime is indeed expected to be restored?

After all files were restored, some datestamps were applied.

(16 Aug was when I did the restore)

Can somebody please confirm if the Created time is expected to be restored too?

Created time isn’t expected to be restored.

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

Here are my 2 cents :

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.

Hm, for me the restored file is not just a copy but the original file, including the creation timestamp.

I am using robocopy on Windows a lot for synchronization of files and folders and it easily copies creation timestamps, too.

Is it really that difficult to implement in restic?