Keeping full precision of file modification timestamp

Does anyone know how to backup and restore files on Windows while keeping the full precision of the file modification timestamp? I followed the Quick Start tutorial (CLI version) to backup and restore from an attached USB drive and all of my restored files seem to have the microsecond portion of the modification timestamps set to zero.

I think this is by design, due to the fact that some cloud storages don’t store a greater precision than this.

Imo this has nothing to do with the cloud storages.

Metadata (file attributes) is stored by :d: in its own encoding which is independent of cloud storage features.

This is either a bug on how the metadata is stored during backup, a bug in how the restore does its thing, or maybe it is the lowest common denominator for {linux, mac, win} to work together.

From what I could gather, the snapshot files store file timestamps with a precision of one second. Recent file systems store timestamps with greater precision, so it would be great if :d: could do the same (at least as an option).

I have programs that rely on these timestamps so, for me at least, this feature would be important.

2 Likes

I just remembered one detail: is your USB drive formatted with FAT32?

No, it’s NTFS. The repository and storage are both NTFS.

Right, currently the timestamp is saved as the unix time so the precision is 1 second. Just curious what programs require more precise timestamps?

2 Likes

I’m not sure which program @RobertN is using, but one example is data from cameras — which can often take multiple photos per second. Truncating the timestamps would mean making it difficult/impossible to sync up photos with other high-precision data if you had to rely on backups.

2 Likes

Something close, data acquisition software actually. Also, I use WinMerge sometimes to compare files and it uses precise timestamps. However, in all cases I think I’ve figured out workarounds, so it’s fine now.

It’s good to confirm that I wasn’t missing something. Thanks for the clarification, @gchen.

1 Like