file changes without updating mtime

From: Erik Paulson
Date: Tue Jun 27 2006 - 14:08:53 EST



Hello -

I'm seeing file content change without a change to the mtime for that
file, and I'm trying to understand why.

The filesystem is ext3, on a local IDE drive. It's a Centos 4.3 machine,
with kernel version: 2.6.9-34.0.1.ELsmp

A shell script that in a loop prints the date, stats the file, and then runs
'md5sum' gave me this output:

Fri Jun 23 04:03:24 CDT 2006
File: `/var/lib/rpm/__db.001'
Size: 16384 Blocks: 32 IO Block: 4096 regular file
Device: 303h/771d Inode: 6291609 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2006-06-23 04:00:24.669054993 -0500
Modify: 2006-06-18 21:42:43.685708137 -0500
Change: 2006-06-18 21:42:43.685708137 -0500
37327d016d9741b0d74e4c9bd14d2956 /var/lib/rpm/__db.001


Fri Jun 23 04:06:24 CDT 2006
File: `/var/lib/rpm/__db.001'
Size: 16384 Blocks: 32 IO Block: 4096 regular file
Device: 303h/771d Inode: 6291609 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2006-06-23 04:04:51.898420485 -0500
Modify: 2006-06-18 21:42:43.685708137 -0500
Change: 2006-06-18 21:42:43.685708137 -0500
b2b25d452c94bb376f172e1789e8ab6e /var/lib/rpm/__db.001


So something else read the file at 4:04:51, and apparently changed it.

I know that mtime can be reset, and that may very well be what's going on.
If that's the case, is there any other way I can from the file metadata
that it may have changed, short of reading it and checksumming? There are
other files that appear to be changing without updating their mtimes - a
number of the kde screensavers, which I think might be the prelinker.

My end goal is to be able to determine when a file has changed without
reading the contents, because I want to read the contents and compare them
to a previous version. If the content I read is not the same as the content
I read last time, I want to know if it's intentional or if there has been
some file corruption. (I am not worried about malicious users changing files
and hiding their tracks). The way I had hoped to go was to use the mtime
and filesize, but that appears not to be enough.

Thanks!

-Erik

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/