[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: tla1.2 on cygwin
Date: Sat, 13 Mar 2004 17:52:48 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]