skip to content

An NTFS file's creation time is weeks later than its modification time — what does that indicate?

level: middleimportance: should knowfreq 54%

answer

  1. the file did not exist here before then
  2. one event happened here, one did not
  3. content brings its own history along
  4. copy makes a new file, move renames one
  5. birth is arrival, modified is inherited

basics

~20 s

It is the ordinary signature of a file arriving as a copy. The copy created a new file here, so the creation time is when it landed, while the modification time travelled with the content from its source.

solid answer

~50 s

Creation later than modification is what a **copy** looks like, not an anomaly. Copying, downloading or syncing a file writes a *new* file on the destination volume: the birth time is the moment it landed, the C (MFT record) time moves with it, and the data-modified time is preserved from the source, so it can be years older. The only event that happened *on this host* is the arrival; the modification time is inherited content history from another volume. Note what it does not give you: it does not name a person or a process, and — because Windows commonly disables or throttles last-access updating — an access time equal to the creation time usually just reflects the write itself rather than somebody opening the file. To attribute the arrival, pivot to an application or proxy record covering that instant.

code

text · 6 lines
text
File: C:\Users\pmarek\Contoso Sync\Q3-pricing\rate-card.xlsx
  M  (data modified)   2026-01-14 09:41:07 UTC
  A  (last accessed)   2026-03-02 22:16:44 UTC
  C  (MFT changed)     2026-03-02 22:16:44 UTC
  B  (created/birth)   2026-03-02 22:16:44 UTC
  ... (all values converted from stored UTC by the examination tool)

go deeper

for a junior

Recall that copying a file gives it a fresh creation time while keeping the source's modified time, so creation later than modification is normal for a downloaded or synced file.

for a middle

Explain the mechanics behind it: a copy writes a new MFT record while an in-volume move only renames one, and say which fields move in each case.

for a senior

Separate the file-system event you can evidence from the human act you cannot, and name the second source — sync client log, proxy record, session record — you would pivot to for attribution.

for a principal

Set the house rule for how such rows are written up: evidenced operation and inferred cause in separate sentences with separate confidence, every time quoted in UTC with the producing tool named.

## What the pattern is The row shows B, C and A clustered on one instant, with M about seven weeks earlier. That is the classic **arrival-by-copy** shape, and on a synced or downloaded file it is the expected shape rather than a suspicious one. ## Why a copy produces it Copying a file does not move the original's identity. The destination gets a **brand-new file**: a new MFT record, a new birth time set to the moment of the copy, and a C value set at the same instant because the record was just written. The **contents**, however, are reproduced along with the source's data-modified time — Windows copy semantics preserve the last-write time. So M reaches back to whenever somebody last wrote the content, on some other volume, possibly on some other machine. Downloads, file-sync clients materialising a file locally, extraction from an archive and copies from a network share all behave this way. The contrast is worth holding: a **move within the same volume** is a rename. The MFT record survives, so B and M stay put and only C moves. A **move across volumes** is a copy plus a delete, so the destination looks like a copy. If you cannot tell which of these produced the row, you cannot yet say the file *arrived* at the birth time from outside — you can only say a new record for it was created on this volume then. ## What you can state, and what you cannot Read the row strictly as file-system operations: - **Defensible:** a file with this content came into existence at this path on this volume at 22:16:44 UTC on 2 March. The content it carried had last been written at 09:41:07 UTC on 14 January, somewhere. - **Not supported by this row alone:** who did it. MACB records the action of a process running under an account; it names neither the process nor a human. - **Not supported:** that anybody read the file after it landed. A equals B here, and on Windows that usually just means the write set it. Last-access updating is disabled or throttled by default in most estates (`NtfsDisableLastAccessUpdate`), and antivirus, backup and indexing agents update it without a person in the loop. - **Not supported:** that the 14 January edit happened on this host or by this user. It is inherited metadata about another volume's history. ## Where the January time actually helps The inherited M value is not noise; it is a **join key**. If the original lives on a file share, an application record or a document-management system, its own history will carry that same last-write time, letting you identify the source object and often the person who wrote it. The pair (content hash, inherited M) is frequently a stronger identifier for "which document is this" than the file name, which anyone can change on the copy. ## Pivoting to attribution What you want next is a **second source that observed the same instant from a different angle**. Around 22:16:44 UTC on 2 March, look for: the sync client's own application log recording the download or upload of that object; a proxy or cloud-application record showing a transfer of the matching byte count to that tenant; an authentication record showing which session was live on that host. Each of those adds something MACB structurally cannot — a process, an account with a session, a destination. ## The framing that goes in the report Write it as two separate sentences with two separate confidences: one sentence describing the file-system event that is directly evidenced, and one sentence describing the inference about how the file got there, with the corroborating source named. If the corroborating source is missing, say the arrival is consistent with a copy and stop. Collapsing both into "the user copied the pricing file on 2 March" is the overreach an opposing reviewer will take apart first, because the file system recorded neither the user nor the copying. ## One more practical trap Before concluding anything about the seven-week gap, check that both values were rendered by the same tool with the same zone assumption. A row where one field was copied out of a spreadsheet in local time and another read straight from the tool in UTC can manufacture or hide a gap all by itself. Quote every timestamp in UTC and record which tool produced it.

  • How would you distinguish a copy from a move within the same volume?
    A move inside one volume is a rename: the MFT record survives, so birth and data-modified times are unchanged and only the record-changed value moves. A copy — or a move across volumes, which is a copy plus a delete — creates a new record, so birth jumps to the moment of arrival while the modified time is inherited. Journal records covering that path, or a surviving source copy, settle which one occurred.
  • The access time equals the creation time. Does that mean nobody opened the file after it arrived?
    No. On Windows, last-access updating is commonly disabled or throttled, so the value often just reflects the write that created the file and would not move even if the file were opened repeatedly. Absence of movement in A is not evidence of absence of reads. If you need to show the file was opened, look for application artefacts — recent-document entries, the application's own log — not the access time.
  • Why is the inherited modification time still useful even though it describes another volume?
    It identifies the source object. The same last-write time, paired with a content hash, usually lets you match the copy back to a specific file on a share or in a document system, along with whoever last wrote it there. File names are trivially changed on the copy; the inherited write time and hash are not.

saying these in an interview costs you the question

  • Calls creation-after-modification impossible or inherently suspicious
  • Concludes the user edited the file on the earlier date
  • Says the named account performed the copy because the file is in its profile
  • Reads an access time equal to creation as proof of a read
  • Compares two timestamps rendered in different zones without saying so

context

resolving links…