Hvad sker der med tidsstemplerne ved kopiering, zip, upload og mail?

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Filens tidsstempler hører til filsystemet, ikke til filen. Hver gang en fil kopieres, pakkes, uploades eller sendes, skal det modtagende system afgøre, hvilke tider den nye fil får, og svarene er forskellige fra handling til handling og fra program til program. Det typiske mønster er, at ændringstiden følger med, mens oprettelsestiden bliver tidspunktet for kopieringen. Men undtagelserne er mange, og det er dem, der giver fejlslutninger i sager om tilbagedatering, kopiering ved fratræden og “hvornår havde vi filen”.

Den grundlæggende forklaring for ikke-teknikere findes på Tidsstempler og tidszoner. Her gennemgås, hvad de enkelte handlinger gør. Hvordan tider fra forskellige kilder vises entydigt i rapporten, står i UTC og sommertid i forensiske rapporter.

Tre lag af tid

Det er nyttigt at holde tre lag adskilt:

Filsystemets tidsstempler: oprettet, ændret, tilgået og (på NTFS) MFT-ændret. De ændres let ved flytning mellem systemer.
Filens interne metadata: fx oprettet og senest gemt i et Office-dokuments core.xml eller optagetid i EXIF. De følger indholdet og ændres ikke ved kopiering, kun når filen gemmes af et program.
Systemernes egne registreringer: serverens modtagelsestid for en mail, cloudtjenestens uploadtid og versionshistorik, auditlogs. De er skrevet af et andet system og ofte de mest pålidelige.

Kopiering påvirker det første lag, sjældent det andet og skaber nye poster i det tredje. Se Metadata i Office-filer.

Kopiering på samme computer eller til et andet drev

På Windows med NTFS gælder som hovedregel:

Kopiering · Ændringstid: Bevares fra kilden · Oprettelsestid: Tidspunktet for kopieringen
Flytning på samme volumen · Ændringstid: Bevares · Oprettelsestid: Bevares
Flytning til andet volumen · Ændringstid: Bevares · Oprettelsestid: Afhænger af program og metode

Resultatet af en almindelig kopiering er derfor en fil, der ser ud til at være ændret, før den blev oprettet. Det er normalt og et af de bedste tegn på, at filen er en kopi. Det er ikke tegn på manipulation. En flytning til et andet volumen er teknisk en kopiering efterfulgt af en sletning, og om oprettelsestiden overføres, afhænger af det program, der flytter. Stifinder og kommandolinjens værktøjer behøver ikke give samme resultat.

Tilgået-tiden opdateres ikke pålideligt i nyere Windows-versioner og bør ikke bære en konklusion. NTFS’ $FILE_NAME-tidsstempler opdateres efter andre regler end dem, Stifinder viser. Se NTFS i dybden og Oprettet, ændret, åbnet: hvad fildatoerne betyder.

Kopiprogrammer opfører sig forskelligt. Nogle kan bevare alle tider, fx robocopy med de rigtige parametre, mens synkroniseringsværktøjer og backupprogrammer har deres egne regler. Kopiering af netværksdrev til sikring er beskrevet i Kopiering af netværksdrev og filshares.

macOS og Linux

På macOS har APFS både oprettelsestid (birth time) og ændringstid. Kopiering i Finder kan bevare begge, så en kopi på Mac ikke nødvendigvis har det mønster med “oprettet efter ændret”, som kendes fra Windows. Kommandolinjens cp sætter derimod som udgangspunkt nye tider, medmindre der bruges parametre, der bevarer dem. Hvilke tider Finder overfører, kan variere med macOS-version og destinationens filsystem, så adfærden bør afprøves, hvis den bærer en konklusion.

Linux-filsystemer som ext4 har ændringstid, tilgået-tid, statusændringstid (ctime) og i nyere versioner også oprettelsestid. Statusændringstiden kan ikke sættes af almindelige programmer og opdateres ved enhver ændring af filens metadata, også når andre tider bevares. Den er derfor et godt kontrolpunkt for, hvornår filen senest blev rørt på det pågældende system. Et værktøj som rsync eller tar kan bevare ændringstiden, men ikke statusændringstiden.

Pointen er, at samme handling giver forskellige spor afhængigt af platformen. En regel lært på Windows kan ikke overføres direkte til en Mac eller en Linux-server.

USB-nøgler og FAT-formater

Kopieres en fil til en USB-nøgle med FAT32 eller exFAT, ændres tiderne i overgangen:

FAT gemmer i lokal tid uden tidszone. Læses nøglen på en computer med en anden tidszone eller efter skift til sommertid, kan tiden se forskudt ud.
FAT32 har to sekunders opløsning for ændringstid og kun dato for tilgået.
Kopieres filen tilbage til NTFS, bærer den den afrundede tid med sig.

En forskel på en time eller nogle få sekunder mellem to kopier af samme fil kan derfor skyldes filsystemet alene.

Zip og andre arkiver

Zip-formatet gemmer som udgangspunkt kun ændringstid, i DOS-format med lokal tid og to sekunders opløsning. Udvidede felter kan gemme tider i UTC og med finere opløsning, og nogle programmer gemmer også oprettet- og tilgået-tid. Hvilke felter der skrives, afhænger af programmet, der pakker.

Ved udpakning sætter de fleste programmer ændringstiden fra arkivet, mens oprettelsestiden bliver tidspunktet for udpakningen. Nogle programmer genskaber også oprettelsestiden, og andre sætter alle tider til udpakningstidspunktet. En udpakket fil kan derfor have en ældre ændringstid end selve zip-filen, og det er forventeligt. 7z og rar har deres egne formater med flere tidsfelter.

Selve arkivet kan være et godt spor: Tiderne inde i arkivet viser filernes tilstand, da arkivet blev lavet, og arkivfilens egen tid viser, hvornår det blev dannet eller hentet.

Upload til og download fra cloud

Når en fil uploades til en cloudtjeneste, registrerer tjenesten sin egen tid for upload og oprettelse i tjenesten. Om filens lokale ændringstid følger med, afhænger af tjenesten og af, om filen kommer via browser, synkroniseringsklient eller API. Synkroniseringsklienter forsøger ofte at bevare den lokale ændringstid, mens upload via browser kan sætte ændringstiden til uploadtidspunktet. Tjenesternes API’er skelner ofte mellem de to: Microsoft Graph har et særskilt felt for den ændringstid, klienten har oplyst, ved siden af tjenestens egen tid, og Google Drive tillader, at ændringstiden sættes ved upload. Hvilket felt en eksport viser, skal derfor fremgå.

Ved download får den lokale fil en ny oprettelsestid. Ændringstiden kan være serverens eller downloadtidspunktet. Downloadede filer på Windows får desuden ofte en Zone.Identifier-strøm med oplysning om kilden. Se Downloads og Mark of the Web.

Mail

En vedhæftet fil sendes normalt uden filsystemets tidsstempler. MIME-standarden har felter til dem, men de bruges sjældent. Gemmes vedhæftningen, får den nye tider på modtagerens computer, typisk tidspunktet for gemning. Filens interne metadata følger derimod med uændret. Mailens egne tider i headere og på serveren er et stærkt, uafhængigt spor for, hvornår filen senest fandtes i den form.

Fortolkning i praksis

Oprettet efter ændret betyder som regel kopi, download eller udpakning.
Mange filer med samme oprettelsestid tyder på en samlet kopiering, udpakning eller synkronisering, ikke på, at filerne blev skabt på én gang.
Ændringstid ældre end filsystemet eller computeren er ikke umuligt, når filen er kopieret ind.
Forskelle på præcis en time peger på tidszone eller sommertid, især ved FAT og zip.
Interne metadata, der ikke passer med filsystemet, skal ses i lyset af, hvordan filen er kommet frem. Se Tilbagedaterede dokumenter.

Er en bestemt adfærd afgørende for konklusionen, bør den afprøves med samme styresystem, program og version og afprøvningen beskrives.

Hvad tidsstemplerne kan og ikke kan bevise

Filsystemets tider på en kopi siger mest om kopien: hvornår den blev lavet, og hvordan. De kan kun sige noget om originalen, hvis det er kendt, hvilke tider kopieringen bevarer. Interne metadata og tredjepartssystemers tider er typisk bedre til at datere indholdet.

Dokumentation

Beskriv i rapporten, hvordan filen er kommet frem: kopieret, pakket, uploadet eller vedhæftet, med hvilket program og på hvilken platform. Angiv hvilke tidsstempler der er filsystemets, hvilke der er filens egne, og hvilke der er registreret af et andet system.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Tidsstempelformater: FILETIME, Unix, Apple og WebKit, og konvertering · Sommertid og tidszoner i rapporten: UTC og den dobbelte time

→ Forensisk sikring · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik