Re: GNAT corrupted builds with below second changes

["Robert I. Eachus" <rieachus@comcast.net>]

On 3/15/2018 3:59 PM, Bojan Bozovic wrote:

> Versioning file system is then what's needed, and that has been in VMS/VAX-VMS/OpenVMS since seventies (and since seventies, VAX had 128 bit integers as well). There's no good reason mainstream OS don't have it (like Windows, Linux and OS X), it's absent only due to inertia. In linux there's NILFS but it's not used in mainstream distributions. DB is partial solution, as files belong to the file system, not the database.
>
Multics had it before that, it was just so invisible (unless you needed 
it) that many users never knew it was there.  Actually, since this was 
Multics, I should talk about segments.  The dumper daemon, ran around 
behind the scene and copied modified segments, usually to tape, but 
could be to hard disk.  How did it know if a file was modified? It 
looked to see if the last changed date was before this pass started. 
What if you made multiple changes in a second?  First, the timestamps 
were guaranteed unique, the timestamp might normally be printed to the 
second, I think the timestamps went to the microsecond.  Even if the 
system clock was slower, and it usually was, any call to the clock got 
the clock plus the number of clock calls since the last clock tic. 
(Shriek names, that began with an exclamation point were guaranteed to 
be system unique and were created by hashing the value from a clock call.)

The policy on dumping segments allowed for segments growing, so every 
keystroke didn't result in a dumped file.  Also tools like compilers 
used !names to insure they wouldn't be dumped, except for those 
resulting segments that were renamed when finished. But for example 
deleting the contents of a segment gave you a new blank segment, and 
Multics held onto the old version, if necessary, until it was dumped.

I only used the capability once. I was testing changes to a terminal 
driver written in Multics Lisp, and wrote all over the source segment 
while testing it.  No problem.  The file system offered me 25 versions, 
and offered to look for more. ;-)

The only real problem was that all system times were in UTS with no 
daylight savings, but printing files would use the local time offset. 
So around the start and end of daylight savings time it could confuse 
users. (The timestamps didn't change, just how they were printed.)

Anyway, I don't care how they do it anything that depends on timestamps 
should make them unique.  Like Multics, the milliseconds or microseconds 
don't need to be accurate, just correctly ordered and unique.