xfs
[Top] [All Lists]

Re: file corruption during emacs build on XFS logical volume

To: Nic Doye <nic@xxxxxxxxxxx>
Subject: Re: file corruption during emacs build on XFS logical volume
From: Austin Gonyou <austin@xxxxxxxxxxxxxxx>
Date: 04 Jan 2002 11:22:15 -0600
Cc: Sean Neakums <sneakums@xxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <1010141444.1992.3.camel@pyewacket>
References: <1010141444.1992.3.camel@pyewacket>
Sender: owner-linux-xfs@xxxxxxxxxxx
No, It does not guarantee. Also, if you're not on the same Inode the
file time is different, etc, it's possible to have different md5sums. A
basic size and file comparison is probably best for what you want to do.

Something you can do to test what I'm talking about is copy each of your
dumps to another name, binfilexyz.1 or something, then compare it's
md5sum against the original. Those should be the only time they match.  

On Fri, 2002-01-04 at 04:50, Nic Doye wrote:
> On Fri, 2002-01-04 at 00:24, Sean Neakums wrote:
> 
> > After I got that bogus dumped binary, I've done about thirty more
> > dumps, by hand.  They all seem to run fine, although I'm getting
> > different md5sums for each of them, even though I'm taking pains to
> > dump each under the same filename.  I'm not sure if the dumping
> > process guarantees identical binaries each time or not.
> 
> I think the binary contains things like the date/time of the build (as
> visible in the spash screen). Hence the different md5sums.
> 
> nic
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@xxxxxxxxxxxxxxx

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>