Editing a docly file over the drive resets its created date

What you'll see

A document you only changed a word in suddenly claims to be new.

• A page edited over the mapped drive shows today's date where it used to show the year it was written.
• A folder sorted or filtered on Created reshuffles after an unrelated edit, and the documents that move are exactly the ones you touched.
• You fix the date by writing the old Created value back over the drive, read the file again, and find today's date there once more.

Nothing reports an error. The edit you intended is applied correctly — only the metadata around it moved.

What's actually happening

The drive does not write your bytes into storage untouched. It hands the file to Docly's document registration, and registration stamps the envelope. On an edit of an existing document both Created and Modified are set to the time of the save, whatever the file you wrote said.

Creating a document is not the same operation and does not behave the same way. Copy a complete .docly in as a new file and the Created and Modified you put in the envelope survive registration verbatim — including backdated ones. The asymmetry is the whole trap: the path where you deliberately set the dates preserves them, and the path where you were not thinking about the dates at all silently replaces them.

Modified moving is correct and load bearing — the published folder cache validates on it and the search indexer picks documents up by it. Created moving is pure loss. It is the one field in the envelope that cannot be recomputed from anything else, and the drive is the only writer that changes it.

It also cannot be repaired from the drive. Writing the original timestamp back is itself an edit, so that save stamps Created with the time of the repair. Each attempt to fix it produces a fresher wrong answer than the last.

What to do

Assume every drive edit costs you the document's Created date, and decide in advance whether that matters. For most content it does not. It matters where the date is content — dated posts, records, anything a template sorts or displays by creation.

Where it matters, keep the date in a field of your own rather than relying on the envelope. A schema field is written by you and is never restamped, so it survives any number of edits:

"Published": "2024-11-03"

Sort and display on that field. This is the same reasoning as Sort folder contents by a custom field — a value you control beats one the platform maintains for its own purposes.

Record the original date before you start editing if you are working through a batch of documents and the dates matter. Read the envelopes first; you cannot recover them afterwards.

Do not try to repair Created over the drive. The repair is an edit and takes the same stamp. If the original date genuinely has to go back, that has to happen somewhere other than the mapped drive.

When you are creating rather than editing, the dates are yours. A backdated Created in a file you copy in as a new document is preserved, so imports and migrations can carry their real dates — see Creating new docly files for the write pattern that gets a new document registered at all.