Re: [Gnu-arch-users] Re: tla1.2 on cygwin

[Aaron Bentley]

Stefan Monnier wrote:
> I'd rather assume that if ctime and size have not changed, then the file
> hasn't changed, even though it's possibly incorrect.

You meant mtime, right? :-)
But what if the mtime and size haven't changed, but the file an utterly 
different file?

For example, in my revlib for tla--devo--1.2--patch-113, 
libarch/cmd-undo.h and libarch/cmd-redo.h have identical sizes and 
modification dates.  Swapping them would not affect any of those 
attributes.

In fact, renames on arch-managed files are very hard to detect without 
looking at inodes, since all of them are created within a few seconds of 
eachother.

> > But I'd hate to go without inode signatures in libraries, because
> > detecting corruption is essential.
>
>
> Detecting corruption is *not* essential when I want to look
> at `tla file-diffs' or `tla changes'.

All of the "changes" and "file diffs" will produce faulty output if the
basis for comparison is corrupt.  While you may not use "tla changes 
--output" in an automated way, others do.  Certainly, I use both 
"file-diffs" and "changes" in ways that require that they do not produce 
faulty output.

> It's even less essential to detect corruption of file BAR when I do
> `tla file-diffs FOO'.

I haven't looked at the code, but I imagine we only look at the 
reference version of FOO.

> And if we really want to detect corruption, how about MD5 instead of inodes?

Performing an MD5sum is much slower than a stat().  It would make "tla 
changes" orders of magnitude slower.

Aaron