This test part of the RealDB project. See site at http://www.gillius.org/realdb/

Testing with CorruptionTest revision 63:

Following up on the tests from 7-13, by placing current timestamp in every block, to try to see where the blocks came from.

What is very interesting is that the entire file came out like I saw before, but the timestamp was, in fact, updated. Unless Windows has a bug where it is caching the file from the last time it saw the disk, the delayed write error was not correct that I lost data, and I must not have pulled out the disk fast enough.

Using file J:\CorruptionTestBlockFile
  with blocksize = 256 bytes

Possible commands:
  allocate <num_blocks>
  clear
  write
  validate
  exit

validate
......25%.....50%.....75%.....100%
Blocks good=0, bad_data=0, bad_block_num=0, clear=16384
New timestamp Mon Jul 14 21:55:28 EDT 2008 found at block 0
Completed validate
write 
Creating file with timestamp of Mon Jul 14 21:57:10 EDT 2008
......25%.....50%.....75%.....100%
Completed write 
<Pulled out the card here>
validate
......25%.....50%.....75%.....100%
Blocks good=16384, bad_data=0, bad_block_num=0, clear=0
New timestamp Mon Jul 14 21:57:10 EDT 2008 found at block 0
Completed validate

Trying again:
clear
Creating file with timestamp of Mon Jul 14 22:00:33 EDT 2008
......25%.....50%.....75%.....100%
Completed clear
write
Creating file with timestamp of Mon Jul 14 22:00:50 EDT 2008
......25%.....50%.....75%.....100%
Completed write
validate
......25%.....50%.....75%.....100%
Blocks good=16384, bad_data=0, bad_block_num=0, clear=0
New timestamp Mon Jul 14 22:00:50 EDT 2008 found at block 0
Completed validate

I tried pulling out the card after I typed write as fast as I could. Maybe the buffered writing is actually causing data to go out faster?

Trying with a larger, 16MB file. This I know can't possibly write faster than in a few seconds based on the flash speed. I do notice that with the larger file the writes are not "instant" -- instead the write in 4-5 chunks.

allocate 65536
Completed allocate 65536
clear
Creating file with timestamp of Mon Jul 14 22:02:42 EDT 2008
......25%.....50%.....75%.....100%
Completed clear
write
Creating file with timestamp of Mon Jul 14 22:03:20 EDT 2008
......25%.....50%.....75%.....100%
Completed write
validate
......25%.....50%.....75%.....100%
Blocks good=65536, bad_data=0, bad_block_num=0, clear=0
New timestamp Mon Jul 14 22:03:20 EDT 2008 found at block 0
Completed validate

I pulled it out REALLY fast after write... this has to be physically impossible. I pulled out the USB device entirely and plugged it back in and it still showed the file proper. So, I try to clear this supposedly "good" file and interrupt in the clear:

clear
Creating file with timestamp of Mon Jul 14 22:05:27 EDT 2008
......25%.....50%.....75%.....100%
Completed clear
validate
....Exception in thread "main" java.io.IOException: The device is not ready

The drive dissappears when I try to read the file now. It seems that no matter what I do, I can't get a corrupted file, either it doesn't read right or something. Somehow, I don't trust the OS, thinking maybe it is playing tricks on me with caching. In fact, I can't even copy the file out with Windows explorer. If I try to do that, the disk just "dissapears". I'll try rebooting and then reading; that should clear past any possible caching idea. After a reboot, the same thing happens again.

Conclusions:
Obviously whatever the OS is doing is not good for me at all, because I need to have feedback on the application side on when blocks are actually committed to the disk, and regardless of what happens with respect to corruption, I need some feedback rather than me being able to dump 16MB to disk at once and have it say it is done even though it clearly could not be.