When running fsx (file system exerciser, from freebsd/apple - http://www.freebsd.org/cgi/cvsweb.cgi/src/tools/regression/fsx/), we are seeing some failures when doing truncate operations. The behaviour seems to be: Open a new file Write some data truncate the file so that it is shorter lseek past the eof - the intervening space should be all nuls (see lseek manpage). Write some data at the new end of the file, thus leaving the hole in the middle. fsx complains that the intervening space is not-nul. I haven't been able to write a straight forward test case, so it is possible that this bug is intermittent, or my interpretation of the fsx output is wrong. Also, the problem seems to go away if I force fsx to only truncate onto page boundaries (multiples of 2048 bytes). I used the following command line to trigger the failure: ./fsx -N 10000 /mnt/foo 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