Preserving Timestamps on DSM – Seeking Best Practices from Archivists or Metadata-Conscious Users

Synology
1

Hello everyone,

I’m reaching out to ask for your thoughts and best practices regarding the preservation of creation and modification dates on Synology DSM. This might not bother everyone — but for those of us who care about accurate file history, this is a serious challenge.

My Goal

I aim to preserve the original created and modified timestamps of my files — particularly photos and documents — across systems and backups. For me, these dates are not just convenience metadata; they represent the authentic context of the content, especially in an archival setting.

What I’ve Observed So Far

  • :white_check_mark: Synology Photos appears to preserve both dates when importing images.
  • :white_check_mark: Copying small batches from macOS to Synology via SMB or mounted SFTP can retain timestamps (though not consistently).
  • :x: Copying inside DSM (e.g., File Station) resets the creation date to the copy time.
  • :x: rsync between NAS ↔ Mac has also changed timestamps, depending on direction and flags.
  • :x: rclone sync from pCloud to NAS with --metadata still results in:
    • Creation Date = Upload Date
    • Modified Date = Old Creation Date
  • :x: DSM tends to override crtime with mtime and crtimewith the time of upload or the time DSM first “sees” the file.

Why I’m Concerned

Many people accept this behavior or consider “modified date = good enough”, but I don’t. From a purist archival perspective, the distinction between created and modified matters:

  • created = when the file/content came into existence
  • modified = when it was last changed
  • Overwriting one with the other breaks historical accuracy

I understand that creation time (crtime) is not a universally accepted standard and was never formally intended to track the moment when a file originally came into existence. However, that’s how many users — myself included — choose to interpret and rely on it, especially in the context of personal archiving.

This concern led me to:

  • :x: Forgo Synology Drive (which rewrites timestamps silently)
  • :white_check_mark: Use pCloud as my source of truth, where files are untouched
  • :warning: Reconsider DSM as my long-term archival backend

What I’m Asking

  • Are there known, stable workflows to preserve timestamps accurately on Synology?
  • Have I missed any methods or flags in rsync, rclone, or Synology tools?
  • Do you use sidecar databases (e.g., SQLite) to track original mtime/crtime/EXIF and restore later?
  • Do you think it’s reasonable to treat the modified date as a stand-in for the creation date when the original isn’t available? Or would it be better to create a new versioned file for each meaningful modification to preserve both?

I’d love to hear if anyone has:

  • Real-world timestamp-preserving workflows
  • Philosophical or technical arguments for timestamp handling
  • Suggestions on how to safely mirror or backup pCloud → NAS without loss

Closing Thought

This is a niche concern — but if Synology is used for archival, I want timestamp integrity be taken seriously. Otherwise, I am storing files without their history.

Thanks so much for any ideas, tips, or challenges to my thinking.

Best,
TheArchivist

2

I’m not seeing this. Copied (drag/drop+ctrl) retains created/modified dates.

3

You’re right—I was mistaken on this point. Both methods are working: drag-and-drop with Ctrl, as well as using the “Copy to” option from the context menu.