File modification/creation should not be upload date

File modification and creation dates should not be upload dat

file datestamp, file timestamp, file version control

Problem

I have web sites on a server running Fedora 31. From a records management and web site administration point of view, I absolutely need the date/time stamp of files to be true. I need to be able to rely on the date/time stamp for version control on my personal sites, and for legal reasons on my client’s sites. Changing creation/modification dates and times by file movement is counter-intuitive. The dates should reflect the data ownership, not the OS opinion.

Behaviour - a file on a web site has a more recent date/time stamp than a newer file on the LAN because the OS has changed the date/time stamp to suit itself. In real data terms, the newer file on the LAN should have the more recent date/time and an FTP app should know to overwrite the web site with the LAN copy. However the app is being told the web site version is newer and not overwriting the file.

FTP apps have the option to only write/overwrite new or more recent files, and this date/time stamping by upload date gives false results.

And, how does one legally prove the date of a document when the time stamp has been changed by the server OS?

Cause

Not yet known.

Related Issues

Bugzilla report: #NNNN

Workarounds

None yet.

Does other metadata from files
Lefts? Or does it remove all?
And what server are you using for this FTP server?

The OS just doesn’t know any better. The file timestamps are what we call “metadata”. They are not part of the file itself, but held by the OS. When the file is uploaded to the server, the uploading client may choose to send file creation or modification times[1], but there is no way to prove that the client is telling the truth[2].

When the file is saved to your server’s filesystem, it will default to giving the date that that happens – but the process doing that saving can choose to assign some other date (like the one provided by the client). It sounds like this is what you want. In that case, it will be a matter of the capabilities and configuration of the server software you’re using — in this case, it sounds like an FTP server. (Is it vsftp?

Crucially in this, there’s nothing that stops the client from lying. They could change the timestamp on their side – or even change the clock on the client computer. In this sense, your server timestamps are more trustworthy — to you, at least. If someone doesn’t trust you, then you’re into the next problem…

This is a very different question. Of course, all bets are off when it comes to what a court might do about technology, but it seems likely that file timestamps are not going to be good evidence. I can think of two things you could do that might be useful:

  1. Log when files are uploaded, with a timestamp and cryptographic hash. You will probably need a third party to hold copies of these logs – possibly something akin to Sigstore. This doesn’t prove anything about the file’s creation, but does let you show when it was uploaded.

  2. Require the client to cryptographically sign their file before upload. Have that file contain a date in a standard format. When they upload the file, the server could a. verify the signature and b. check that the date is within a reasonable range (for example, on the same day as the upload) and reject i it’s wrong.

Neither of these are legal advice, of course – just things that I think would be easy to demonstrate and explain if ever needed.

You may also be interested in this:

RFC4998 - RFC-Wiki



  1. Important note! Traditionally, Unix filesystems do not record “creation time” at all. It was considered too vague of a concept. If you have a digitized copy of the Magna Carta, should that be the date the original document was made? The time it was scanned? The time that scan was copied somewhere? Btrfs, the default on many Fedora Linux systems now, does keep a creation date, but … all of these problems apply. ↩︎

  2. although one can be suspicious if the server thinks that time is in the future! ↩︎