Hi,
Love4Boobies wrote:Brendan wrote:I'm thinking about things like "make" failing to work because the new file's have timestamps that are older than the old binary's timestamp, and incremental backup utilities that don't backup new files because the new file's timestamps are older than the last backup, and scheduled tasks that are meant to be done at 12:00 each day but are skipped completely because the time went from 11:30 to 12:30 (or are done twice because the time went from 12:30 back to 11:30).
And things could still fail in the same way even in your scenario, only the probability that this would happen would be lower, esp. on slower machines. However, think about using make to build an OS. You probably also have a lot of files that might get updated in less than half a second...
Lots of files being updated in less than half a second is easy enough to fix - just use high precision timestamps (e.g. nano-seconds since the epoch) and/or make sure each timestamp is unique. For example, (in the extreme case) instead of using a timestamp you could just use a counter that's increased by one each time a "timestamp" is requested, so the first file that's modified gets "timestamp = 1", the second file gets "timestamp = 2", etc.
Of course you could combine both techniques - for example, you could have 64-bit timestamps where the highest 32-bits contains "seconds since the epoch" and the lower 32-bits is a counter that's increased by one each time a timestamp is requested (where the counter is reset to zero if the second changes). In this case timestamps might go 0x1234567800000000, 0x1234567800000001, 0x1234567800000002, 0x1234567800000003, ..., 0x1234567900000000, 0x1234567900000001, 0x1234567900000002.
Love4Boobies wrote:Some of these sorts of problems (but not all of them) can be avoided with careful programming, but even when the problem can be avoided most application programmers won't realize the problem exists and they'll stuff it up anyway...
Actually, now that you've mentioned it... I see no obvious workaround for the
make problem. The same applies when the user himself chooses to change the system time. Should he be disallowed to do so?
A user (e.g. root or admin, but not necessarily any user) should be allowed to change the "target" system time, and the OS should gradually make the "current" system time match the "target" system time. Of course there's cases where the OS can cheat. For example, you could keep track of the last used timestamp in the file system/s, and then during boot you could do something like:
Code: Select all
if(target < current) {
if(target > previous_FS_timestamp) {
current = target;
} else {
current = previous_FS_timestamp + 1;
}
} else {
current = target;
}
You could also remember when the system time was last read, and apply changes retro-actively. For example, if the current time is 1:00 and the user sets the target time to 2:00, then if the time hasn't been read for 30 minutes you could pretend that you started adding 1.5 seconds to the system time each second half an hour ago (e.g. immediately set the current time to 1:15 and add 1.5 seconds per second after that).
Maybe sending some sort of signal to applications to notify them that the time has changed so they can handle it appropriately would be best.
That can get very complicated very quickly - imagine if the root user can't make up their mind and changes the "target" time 20 times in half an hour. Applications would need to track an arbitrary number of changes, and when an application reads a timestamp for a file it'd need to figure out which changes have been applied since the file was created to figure out what the timestamp should have been. Of course this isn't possible if the time has been turned back - you could create a file with 12:00 as the timestamp, then an hour later you could turn the clock back by an hour and create a new file that also has 12:00 as it's timestamp, and no application would be able to figure out which file was created when (even if it does track time changes).
For most of these cases it's enough for the OS to guarantee that later timestamps are always numerically higher than earlier timestamps (with no need to make the timestamps correspond to any time scale). For other cases it's not so simple, and the OS would benefit from having "sleep_until(specific_time)" which is effected by system time changes and "sleep_for(specific_duration") which is never effected by system time changes.
Cheers,
Brendan