Re: [jamboost] Timestamps

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-05 09:26:59

----- Original Message -----
From: "Markus Scherschanski" <mscherschanski_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Wednesday, June 05, 2002 11:16 AM
Subject: RE: [jamboost] Timestamps

>
>
> > -----Original Message-----
> > From: Steven Knight [mailto:knight_at_[hidden]]
> > Sent: Wednesday, June 05, 2002 2:44 PM
> > To: 'jamboost_at_[hidden]'
> > Subject: RE: [jamboost] Timestamps
> >
> >
> > > The solution would be, that a timestamp is only different
> > when it differs
> > > more than 2 seconds.
> >
> > I don't think that fixes the whole problem.
>
> That was my first tip - don't know...
>
> > That would fix it if the onlly problem were seeing false differences:
> > two timestamps that you detect are only one second apart, and you have
> > to treat them as if they were really the same.
>
> Okay, that's right.
>
> > The real thorny part of the FAT filesystem is false *matches*: the
> > source file is updated one second after the target file, but the
> > two timestamps are the same because the update occured in the same
> > two-second period for the FAT file system.
>
> So, maybe we should just always add two seconds to the target??!?!

If you can keep track of everything that gets built *and* you have access
to something which can modify the files' mod. time, *and* you don't mind
inaccurate but consistent mod. times, you can change the mod time of any
target that still has the same or earlier time as any of its sources after
its build action completes.

It's a bit of a hack, but I think it should work for real-world builds.

> > I don't see any way to detect false matches without going to
> > some scheme
> > that avoids timestamps completely in favor of using the real file
> > contents.
>
> Yeah, that would be good, MD5 or CRC32?! ;)
>
> But that would be rather slow and not secure in some unfortune cases.

Yeah, I would rather do the mod-time hack above and only use MD5 as a last
resort when we really think the file needs updating, because my impression
is that it would be faster.

I'm not sure there's a real security problem, but SK can say better than I.

However, I am somewhat inclined to leave this sort of rebuild-accuracy
concern to Scons, and to concentrate on higher-level build architecture for
Boost.Build. A conservative scheme which treats targets as outdated if the
sources were modified within the accuracy window is probably good enough
for us, for the time being.

-Dave