From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Robert I. Eachus" Newsgroups: comp.lang.ada Subject: Re: GNAT corrupted builds with below second changes Date: Sun, 18 Mar 2018 01:21:49 -0400 Organization: Aioe.org NNTP Server Message-ID: References: <2e250363-97a3-45bd-948e-081e24d70655@googlegroups.com> <61dc87c3-30f1-4bbb-9125-89ec6e5dfc2e@googlegroups.com> NNTP-Posting-Host: fZYVf2g/avGnWJvs1xVPEA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:51053 Date: 2018-03-18T01:21:49-04:00 List-Id: 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.