hi, vi, without an apparent reason, began to segfault on us. rpm -Vf `which vi` showed that the md5sum was incorrect. The timestamp on the file was unchanged. The substance of the problem is that two bytes in the vi binary have spontaneously become zero's. These bytes do not have a significant effect on the code, but do make it stop working: $ diff -u vi.hex vi.oops.hex --- vi.hex Thu Sep 13 08:58:03 2001 +++ vi.oops.hex Thu Sep 13 08:57:56 2001 @@ -9981,7 +9981,7 @@ 26fc0 88 c2 89 95 50 ff ff ff 83 c4 f8 6a 64 a1 3c ca .Â..Pÿÿÿ .Äøjd¡<Ê 26fd0 0d 08 50 e8 28 cf 01 00 83 c4 10 85 c0 0f 95 c0 ..Pè(Ï.. .Ä..À..À 26fe0 31 d2 88 c2 89 95 4c ff ff ff 83 c4 f8 6a 78 a1 1Ò.Â..Lÿ ÿÿ.Äøjx¡ -26ff0 3c ca 0d 08 50 e8 06 cf 01 00 83 c4 10 85 c0 0f <Ê..Pè.Ï ...Ä..À. +26ff0 3c ca 0d 08 50 e8 06 cf 01 00 83 c4 10 85 00 00 <Ê..Pè.Ï ...Ä.... 27000 95 c0 31 d2 88 c2 89 95 48 ff ff ff a1 60 5c 0d .À1Ò.Â.. Hÿÿÿ¡`\. 27010 08 c7 05 a0 57 0d 08 00 00 00 00 83 78 50 00 75 .Ç. W... ....xP.u 27020 43 83 7d 9c 00 75 3d 83 7d 98 00 75 37 83 c4 f8 C.}..u=. }..u7.Äø This machine is running kernel 2.4.4 and reiserfs. The disk is a 20G ST320413A IDE disk (PIIX4 chipset revision 1). interesting problem : could be a file system error in reiserfs but then how did it write to the binary ? and only the one ? wich means it could be a security problem ? obvious things eg. tripwire, snort, other binaries, -- checked, no obvious signs of compromise. running no services with known holes. thanks, doVe