Metadata (creation timestamps) lost after restore

Bug
#1

I backed up a folder that had a file (file1) and a subfolder containing another file (file2). Then I deleted everything and restored everything back in place.

After restoring you would expect everything to have the same exact creation/modified/accessed dates (in Windows) they did before being deleted. But instead, the subfolder’s creation date is changed to when it was restored, as is the creation date of the file within the subfolder (file2).

The file in the top folder (file1) retains all of the original timestamps. So at the very least, the behavior is inconsistent depending on whether the file is in a subfolder or not.

It seems like a small issue, but if you use creation timestamps to search or filter for files, you’d lose all of those creation timestamps if you ever had to restore from backup.

9 Likes
#2

Duplicacy only stores the modified time, not the creation time.

#3

So what does this mean? It’s not a bug, I guess, but perhaps a design flaw? Should this topic be converted into a feature request?

3 Likes
#4

I tested this again and it seems like there are cases where Duplicacy preserves the creation timestamp. If I create a file in the highest/root folder, make a backup/snapshot, delete the file, and then restore it, the creation timestamp is preserved. However, if it’s in a subfolder or if additional snapshots are made afterward then the restored file loses that creation timestamp.

#5

Any updates on this? IMO it’s pretty important for a backup tool to store the file metadata for the restore to be correct.

Related thread: Arq alternative? : Arqbackup

6 Likes
#6

It is interesting for me, too!

3 Likes
#8

I would really like to see this implemented as well.

1 Like
#9

Wow, just finding out about this :(. Preserving all meta data is obviously critical for such a backup tool. I can’t believe this hasn’t been addressed already (of course, you only realize the issue when you try to restore). There is literally zero downside to it (just some work), only upside (not losing this valuable data). Is this in the roadmap somewhere?

2 Likes
#10

+1 this a major turnoff for me…I use creation dates to look for things sometimes.

2 Likes
#11

Agreed, i’d expect all metadata to be preserved

#12

Hi there,
I would like to second that preserving all timestamps metadata is a necessity. Perhaps @gchen may reconsider his view on this feature.

#13

@gchen I just came across this thread as someone recently bumped it and I have to say I’m quite bummed out about the lack of creation date back up.

To me it’s really a basic feature that lets me know at a glance in any file manager what point in time a file dates from and that allows for quick sorting of files in a folder, which can be very useful if I don’t know the filename or its exact location.

Not happy with my different previous backup programs, I was slowly making the move over to Duplicacy as I like the features it offers and while the GUI still lacks a number of features, just recently I purchased a license for two computers.

Stumbling over this thread (and I didn’t see this lack of creation date keeping documented anywhere and to be honest I didn’t expect such a (in my eyes essential) function to be missing), I’m really hoping that you would reconsider adding support for this. If possible I’d also like to see an option to have at least new revisions to also include the creation date for already backed up files.

Thank you very much!

2 Likes
#14

@gchen Can you please address this? Why does Duplicacy store the date modified attribute but not date created? I use Duplicacy to backup Obsidian notes, and when I restore the notes, the date created attribute is not preserved but instead shows the date which the files were restored on. This is a massive problem when it comes to filtering notes by creation date.

1 Like
#15

I just purchased Duplicacy. I didn’t realize it doesn’t preserve such metadata until now. @saspus in this post you say it preserves the creation date. Has this been implemented, now?

#16

I gave it a try with some sample files. It worked for me. Both the creation timestamp as well as the last modified timestamp were preserved. @gchen I hope it works intentionally? I am just curious as you haven’t responded to this thread for 5 years and I’d build my backups upon the assumption both timestamps could be restored.

This almost prevented me from using Duplicacy. Side notes: backing up empty files and empty folders did also work. I mean they were restored successfully. Only the GUI doesn’t show them upfront in the tree view on the restore page (used version: duplicacy_web_qnap_x86_1.8.0.qpkg + CLI 3.2.3 + RSA encryption).

#17

Can you test whether subfolders and the files within the subfolders retain the timestamps? If you read my original post, the issue was with folders and files deeper in a path. (So restore a folder that has a subfolder with a file in it.)

Also, we should note which operating system it’s tested on, as I’ve seen other backup solutions restore timestamps correctly on Mac/Linux but not Windows. My test was on Windows.

I would also test whether they were restored correctly from earlier snapshots, not just the latest snapshot, as that also caused different results (per: Metadata (creation timestamps) lost after restore - #4 by 65d3784c729f4c099b15).

#18

I did a couple of tests with subfolders and files within them. I didn’t manage to break it. It got restored as intended. I verified the timestamps from Windows 11 with the Windows Explorer (SMB to a QNAP file share where the files are restored from the official QTS package).

I even deleted the entire content of the folder and made a backup. Then I restored the previous snapshot, not the latest. (side note: actually I had to create a new file, as Duplicacy will complain about entirely empty root folders of a backup folder. It’s a little bit confusing for me that it doesn’t backup the folder itself but its contents instead).

Still, I am confused it seems to work (though very happy). Because you’re initial post would’ve been a feature not a bug, according to:

Now I see Duplicacy stores both, even though it shouldn’t. Maybe I am the one that should create a bug report :smiley:

1 Like
#19

Why? Modified time is an important piece of metadata.

#20

I think he meant it seems to store creation time, even though the developer said it does not (at least back in 2019).

2 Likes