Filesystem dates without a clock

[Sik]

Something I was wondering: what happens if you need to write a file but your OS doesn't keep track of the time of the day so you can't provide a valid timestamp? Surely this situation has happened with embedded systems before? I know the earliest PCs didn't have a RTC but DOS just prompts you for the date on those.

I imagine the answer would be to write a bogus timestamp but I'm not sure what that should be.

[alexfru]

You could take the last date/time from the file system and use it.
You could also add the time from the timer (you should have one separate from the clock) to that date/time.
It may be better than nothing because at least it will preserve the order of file accesses.
If your system timer isn't functioning, your system will be dead, unless it is specifically designed to work without one.

[Sik]

Last date/time won't really work for new files (for existing files you can keep the original timestamp at least). Unless you're suggesting to scan the entire filesystem just to figure out what the newest timestamp is (ouch, and may still not work if there aren't any files present yet, e.g. it's a brand new partition).

There's the vertical blank interrupt acting as a 60Hz timer, but when your timestamp is a counter that counts up from 0 on every boot it doesn't really sound suitable for the job (unless you want to interrupt the user to enter the time every time like DOS used to do, which may feel arbitrary if time is otherwise not used anywhere else).

[alexfru]

Unless you're suggesting to scan the entire filesystem just to figure out what the newest timestamp is (ouch, and may still not work if there aren't any files present yet, e.g. it's a brand new partition).

I don't know about the details of many file systems, but it's possible that the FS has the newest timestamp easily accessible in the meta data. Just like FAT32 has a couple of fields saying how many free clusters there are and where to start looking for them (these should be updated before shutdown), there can be the time of the last access stored somewhere.

But other than that, if you don't have the current date-time, you don't have it. And so you may need to figure out the best action when you lose the date-time. I still think, having accurate relative timestamps is better than just giving files some fixed date-times. Perhaps, you want to have both, the timestamp field and a flag that tells that the timestamp is approximate.

You could probably also use light, temperature, humidity and pressure, all those things, to tell apart day from night and summer from winter. But now your system is much more complex and it's likely that you'll have problems with those sensors before the clock breaks or the clock will break simultaneously with some of those.

[sj95126]

I imagine the answer would be to write a bogus timestamp but I'm not sure what that should be.

You could just set it to whatever zero corresponds to, similar to how Unix's time_t 0 is Jan 1, 1970 00:00:00 GMT.

I'm almost certain I remember coming across floppies in the mid-80s that had timestamps from 1980. The FAT12 filesystem was introduced in QDOS (the predecessor to MS-DOS) in August, 1980, so they may have chosen that as their epoch.

[Sik]

I don't know about the details of many file systems, but it's possible that the FS has the newest timestamp easily accessible in the meta data. Just like FAT32 has a couple of fields saying how many free clusters there are and where to start looking for them (these should be updated before shutdown), there can be the time of the last access stored somewhere.

I thought about that when you said that, but I checked both FAT32 and ExFAT and neither of them does. Each file has a timestamp and that includes subdirectories but the root directory doesn't have an entry (it's the very first entry in the filesystem) so it doesn't necessarily have one either.

And yeah, I guess using the filesystem's epoch is the only reasonable option when there isn't a date from anywhere.

[alexfru]

I don't know about the details of many file systems, but it's possible that the FS has the newest timestamp easily accessible in the meta data. Just like FAT32 has a couple of fields saying how many free clusters there are and where to start looking for them (these should be updated before shutdown), there can be the time of the last access stored somewhere.

I thought about that when you said that, but I checked both FAT32 and ExFAT and neither of them does. Each file has a timestamp and that includes subdirectories but the root directory doesn't have an entry (it's the very first entry in the filesystem) so it doesn't necessarily have one either.

And yeah, I guess using the filesystem's epoch is the only reasonable option when there isn't a date from anywhere.

If you need to use e.g. FAT32, you could create and maintain a special file just for that, for tracking the last known date/time.

[bzt]

Something I was wondering: what happens if you need to write a file but your OS doesn't keep track of the time of the day so you can't provide a valid timestamp?

If your OS does not keep track of time, all timestamps will be 0 (or EPOCH), simple as that.

Surely this situation has happened with embedded systems before?

Nope. I don't know of any embedded system that hasn't got at least one timer. Without an RTC the timer starts at 0, that's all, but it always does keep track of elapsed time.

I know the earliest PCs didn't have a RTC but DOS just prompts you for the date on those.

Wait a minute, that didn't mean there's no keeping track of time! BIOS used PIT (then on later models RTC) to monotonically increase a time counter at 40:6C. On boot DOS asked for the current date and time, and it just added the daily counter to that to get the current timestamp, simple as that.

I imagine the answer would be to write a bogus timestamp but I'm not sure what that should be.

Nope, the answer is to keep track of time with a counter. If you start the counter at 0, then you'll get a boot time timestamp (relative to EPOCH), or if you can read it from the CMOS (with RTC) or the user provides a starting value then you'll get a valid timestamp.

Just for the records, this is the same for Linux. Linux does not use any RTC functionalities except getting the current timestamp on boot. Then it uses the configured clocksource to increase a counter. That's why you need to issue "hwclock --systohc" to set the date time in the CMOS.

Cheers,
bzt