I am going to have to get clarification from the team on what is actually backed up for folders. I know you're using an image backup where that metadata exists, but I see the same restore behavior for file backups. I sent this over to the support and engineering teams for review and I'll reply here when I hear back - might not be until Tuesday because of the US holiday.

Sounds good, thank you.

It looks like that's the current behavior of the product. We create the folders at restore time, and those folders will have a create date when the restore is taking place. If you'd like support to note your request you can go ahead and open to support case. I've also sent over some of the case notes and information to the product management team in charge of that product and they may review and add a new requirement in the future.

I guess I would just ask from you to explain in some detail why the folder create date being restored is important. Is there some process that you're doing that relies on it, or is it something that you just noticed and were wondering why the create date was the restore date?

Ok, thank you for the answer.

For what it's worth, I did verify that not only the timestamps for folders but also the timestamps for files change when they are restored. We think having the option to retain the original timestamps on restored files and/or folders could be useful.

To answer your question, we don't have any immediate need for this feature, but we could see a situation where a customer of ours would want to keep the original creation date of a folder or file, post restore (maybe to help them find certain folders or files by when they were created). It's my understanding that the data copy software Robocopy gives you the option to retain the original timestamp after copying, or to have it changed to the date of the copy. We think a feature similar to this could be useful in certain situations. The flexibility that Robocopy offers could be useful:

/copy:<copyflags> Specifies which file properties to copy. The valid values for this option are:
D - Data
A - Attributes
T - Time stamps
S - NTFS access control list (ACL)
O - Owner information
U - Auditing information
The default value for this option is DAT (data, attributes, and time stamps).

/dcopy:<copyflags>
Specifies what to copy in directories. The valid values for this option are:
D - Data
A - Attributes
T - Time stamps
The default value for this option is DA (data and attributes).



Thank you again for answering our question.

You're looking at the Create Date, presumably. I tend to look at the Modified Date in File Explorer as the default datetime field, but that's just me. We do restore the modified dates.

We likely have access to the file / folder information in image backups. I do not know what we store for File Backups, but you're right that we could certainly restore that information, if saved. We have not had a request to restore create dates until now - it's officially logged as a customer request in the system.

But is having the Modified Date retained from the original sufficient, do you think, for most of your customers?

Hello,

I think in the past I've been saying "Create Date", but I've meant to say "Modified Date". Sorry for the confusion, that was my mistake.

Are you saying that the Modified Date should be retained for a file or folder, after a restore?

In our experience with running a file restore from an image backup, this has not been the case. The Modified Date has changed to the restore date.

I’ll have to check. I believe I did a file restore as a test. Stay tuned…