Mail Archives: djgpp/1998/05/04/09:40:42
On Mon, 4 May 1998, Shawn Hargreaves wrote:
> I've seen this problem a few times on my machine at work (p333, w95),
> and it prints "File has timestamp in the future" and then aborts.
If it aborts, then you have an old version of Make. Make 3.76.1 (I think
3.76 as well) just prints a warning there.
> >Besides, it's not Make that's broken, it's the Windows filesystem.
>
> Absolutely. Or perhaps the DOS function call emulation is just returning
> wrong data.
No, the Win32 port of Make also sees this problem when it runs on FAT
disks, even under NT. It seems like the FAT/FAT32 functions in the
IFSMgr (or wherever they are) are the culprit, not the DOS emulation.
> If the internal 32 bit filesystem was in error, surely a lot
> of native windows programs would have similar problems?
My guess would be the other Make's just don't check this, so they are
oblivious to the problem.
> >Can somebody explain how could a filesystem set time stamps of files
> >it creates to be 2 seconds in the future relative to the system clock,
>
> Wild guess: perhaps the time is set according to when the cache is
> flushed to disk, rather than when the data was actually written by the
> program?
I thought about this, but I find this hard to believe. The test program
used to gather data about this runs these checks in a tight loop,
typically many times a second, so the file time is checked long before the
cache is flushed (if that delay is indeed 2 seconds).
It could be that somebody wanted to estimate the time data *will* be
written by the cache. But that would mean that the cache operates on the
file level (i.e. it deals with files, not with clusters of data, like
SmartDrv does). If that is the case, then it is even more mad than I
thought it was.
- Raw text -