Re: Are there Windows users of cons? Steven

[Steven Knight]

On Tue, 28 Aug 2001, Frank Thomas wrote:
> at least all unixes I know of have no way to manipulate ctime. It is the
> time this inode has changed the last time.
        .
        .
        .
> Am Dienstag, 28. August 2001 um 00:35 schrieb Zachary Deretsky:
> > 4. And, finally, for Tony's fix, I could not find a C or C++
> > function in msdev (let alone perl) which allows to manipulate ctime
> > and mtime. But Tony's experiment is well documented and the logic
> > of his patch is very clear. It does not slow cons execution for my
> > builds. Putting that fix in will save the Visual Studio users from
> > the impression that verification of whether file has been changed is
> > broken.

It doesn't have to be a direct way to manipulate the ctime value.  It
can be as a side effect of some other change to the file/inode.  It
doesn't have to be the same call on both *nix and Win32.  It doesn't
have to be in Perl.  It could be a library/DLL call that gets compiled
into a small utility routine from in-line code.

Within that broader set of guidelines, any suggestions?

I did do a quick experiment to see if chmod() would change a file's
ctime, but it didn't.  (On Linux, anyway; I'm currently on vacation and
don't have ready access to the primitive NT setup that I use as a sanity
check.)

I'd be happy to put in a change like this without a test for it.  But
without a regression test for a subtle capability like this, guaranteed
that it will get broken by some change some time within the next 3-5
years or so.  If the test doesn't get written now, when the code goes
in, the odds are slim to none that someone will go back and add it
later.  So this is *the* chance to make sure that not only does this get
added, but that it also doesn't break in the future.  I'd prefer that
it not look like Cons ignores Windows users by not providing adequate
regression tests for important Windows features...

        --SK