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? :-)
> >    
>
> Actually no: I meant ctime.
> mtime can be tweaked with touch, so you can't rely on it if you want to
> be safe.
That's the entire point.  ctime doesn't change when the file is 
modified.  mtime does, unless you're using special tools.  Modification 
== corruption, so that's what we care about.

> > But what if the mtime and size haven't changed, but the file an utterly
> > different file?
> >    
>
> That can happen while keeping the inode constant as well.
>  
Only by using tools that deliberately set mtime.  If the mtime changes 
or size changes, you've updated the contents.  If the inode changes, 
you've updated the name.

> > 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.
> >    
>
> Looking at the ,,inode-sigs files, you can easily find all the files with
> the same mtime and size, so maybe you then do something clever, like "assume
> there's no swap" (which means that as long as there's no file added or
> missing from the list of files with same mtime and same size, you know
> there has been no change).
>  
What I mean by arch-managed files is "revision libraries and 
pristines".  Sorry for the ambiguity.

> > All of the "changes" and "file diffs" will produce faulty output if the
> > basis for comparison is corrupt.
> >    
>
> Sure.  Corruption can and does happen without changing any inode number,
> mtime, or size.  We had better start by deciding from which kind of corruption
> we want to protect ourselves, otherwise "corruption" is a moot argument
> since you'd then have to constantly check everything (including tla, the
> libc you're linking against, locking everything to avoid race conditions
> (the revlib could get corrupted after you checked the inode but before you
> read the file)).
>  
Corruption of the revlib is not uncommon if you use hardlinked trees.  
It must be detected.   These types of corruptions can be detected by 
checking inode sigs, since they usually change mtime and size.  Failure 
to check it will lead to corrupt archives.

> > > 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.
> >    
>
> I doubt it.  On a small project, `tla file-diffs' is essentially
> instantaneous, whereas on an Emacs tree, it takes several seconds.
>  
Okay, I'm wrong there.  Perhaps file-diffs can be more fine-grained.

> > Performing an MD5sum is much slower than a stat().  It would make "tla
> > changes" orders of magnitude slower.
> >    
>
> Why would it be?  If you're not going to read the file, why would you check
> its `stat' for corruption?  You only need to compute the MD5 on files that
> you actually read, so it shouldn't cost much.
>  
To compute a changeset using "changes", you need to compare every file 
against something.   Typically, we check against the inode signatures as 
a shortcut, but if that doesn't work, we fall back to checking against 
the revision library or pristine.  In that case, (i.e. YOUR case) we 
need to check every file in the tree.

Aaron