Just to add to this - the same results happen when using non-mmap reads/writes (-R & -W to fsx). Results: READ BAD DATA: offset = 0x2f5dc, size = 0xa930 OFFSET GOOD BAD RANGE 0x2f5dc 0x0000 0xd76c 0x 78 .... 493(237 mod 256): READ 0x68f2 thru 0x11c70 (0xb37f bytes) 494(238 mod 256): WRITE 0x7c8e thru 0x1604a (0xe3bd bytes) 495(239 mod 256): READ 0x14eca thru 0x1ea7a (0x9bb1 bytes) 496(240 mod 256): READ 0x84eb thru 0x156c4 (0xd1da bytes) 497(241 mod 256): TRUNCATE DOWN from 0x1ea7b to 0x5120 498(242 mod 256): READ 0x35b8 thru 0x511f (0x1b68 bytes) 499(243 mod 256): WRITE 0x388ee thru 0x3ffff (0x7712 bytes) HOLE ***WWWW 500(244 mod 256): READ 0x2f5dc thru 0x39f0b (0xa930 bytes) ***RRRR*** So it did a read @0x2f5dc, which should have been a hole in the file (after the truncate down to 0x5120), but it got back non-zero data. Andre Andre Renaud wrote: > I've attached the truncated output of fsx, although the relevant parts > are the top: > READ BAD DATA: offset = 0xdd7c, size = 0xd933 > OFFSET GOOD BAD RANGE > 0x f000 0x0000 0x6c22 0x 7fc > > and the bottom: > 9602(130 mod 256): MAPREAD 0x2d86c thru 0x382f1 (0xaa86 bytes) > 9603(131 mod 256): TRUNCATE DOWN from 0x3c5fd to 0xb013 ******WWWW > 9604(132 mod 256): WRITE 0x19606 thru 0x282e0 (0xecdb bytes) > HOLE ***WWWW > 9605(133 mod 256): WRITE 0x1d4e2 thru 0x1dfd5 (0xaf4 bytes) > 9606(134 mod 256): MAPREAD 0xdd7c thru 0x1b6ae (0xd933 bytes) > ***RRRR*** > > This indicates that at offset 0xf000, it was expecting to read nuls > (GOOD: 0x0000), but it read non null (BAD: 0x6c22), having done a > truncate down to 0xb013, > > Does anyone know about anything like this? > Andre -- Bluewater Systems Ltd - ARM Technology Solutions Centre Andre Renaud Bluewater Systems Ltd Phone: +64 3 3779127 (Aus 1 800 148 751) Level 17, 119 Armagh St Fax: +64 3 3779135 PO Box 13889 Email: arenaud@bluewatersys.com Christchurch Web: http://www.bluewatersys.com New Zealand