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.1 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,c397a9e135b263db X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-03 07:35:15 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.uchicago.edu!news-hog.berkeley.edu!ucberkeley!192.50.8.47.MISMATCH!newsfeed.media.kyoto-u.ac.jp!sjc-peer.news.verio.net!news.verio.net!iad-read.news.verio.net.POSTED!kilgallen From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: What happens to DEC Ada? Message-ID: References: <9ff447f2.0107310659.36d01e9@posting.google.com> <%jra7.3545$257.153834@ozemail.com.au> Organization: LJK Software Date: 3 Aug 2001 10:35:10 -0500 NNTP-Posting-Host: 216.44.122.34 X-Complaints-To: abuse@verio.net X-Trace: iad-read.news.verio.net 996849314 216.44.122.34 (Fri, 03 Aug 2001 14:35:14 GMT) NNTP-Posting-Date: Fri, 03 Aug 2001 14:35:14 GMT Xref: archiver1.google.com comp.lang.ada:11218 Date: 2001-08-03T10:35:10-05:00 List-Id: In article , "nicolas" writes: > "Larry Kilgallen" a �crit dans le > message news: jGvPbYAYRtuu@eisner.encompasserve.org... >> > Beside that, the timestamp method cannot always be trusted. >> > We had problems with gnatmake which doesn't always recompile necessary >> > files. >> > The problem occurs when several files in different directories have same >> > name, same timestamp, and are selected with ADA_INCLUDE_PATH >> > timestamp and name of the file is checked, they are the sames, gnatmake >> > doesn't figure out that this is a different file and doesn't recompile > it. >> >> Well that sounds like just an implementation bug rather than a >> conceptual flaw. >> > > We recompiled gnatmake with debug messages to see what went wrong actually. > But I'm not sure you can call that an implementation bug. > The flaw is to consider that 2 files with same name and same timestamp have > the same content, > or moreover that the content of a single file has not changed, if the > timestamp has not changed > A lot of batch, or cvs import, commit or extractions, can generate a lot of > files with same name and same timestamp. But unless they are the same bits on the disk, they are a different file. On VMS you would use the 6 byte file ID and the 64 byte device ID to determine uniqueness. I am sure the same construct must exist on other operating systems. Granted, someone writing a tool may neglect to consider the situation you describe, but that is still just an implementation bug.