The very first version of F3, version 1.0, is here. It doesn't have a nice report, and due to a bug, only works properly on 2GB cards or less. It's here just for reference. The code of this version is smaller than the one of the current version, and fixing the bug is a nice puzzle, so have fun!
The version 1.1 of F3 adds a nice report at the end of the output of f3read, and works fine with large memory cards.
The version 1.1.1 just fixes some warnings issued by gcc when the parameter -Wall is used to compile the source.
The version 1.1.2 handles an I/O error reported by Misha Aizatulin. The outputs that he obtained were as follows:
$ ./f3write /media/disk/
Free space: 122.01 GB
Creating file 0001.fff ... OK!
...
Creating file 0113.fff ... OK!
Creating file 0114.fff ... OK!
Creating file 0115.fff ... OK!
Creating file 0116.fff ... OK!
Creating file 0117.fff ... OK!
Free space: 0.00 Byte
Writing speed: 5.96 MB/s
$ ./f3read /media/disk/
SECTORS ok/corrupted/changed/overwritten
Validating file 0001.fff ... 0/0/0/2097152
Validating file 0002.fff ... 33280/0/0/2063872
Validating file 0003.fff ... 0/0/0/32 - NOT fully read
Validating file 0004.fff ... 0/0/0/2097152
Validating file 0005.fff ... 0/0/0/24192 - NOT fully read
Validating file 0006.fff ... 0/0/0/32 - NOT fully read
Validating file 0007.fff ... 0/0/0/32 - NOT fully read
...
Validating file 0035.fff ... 0/0/0/121984 - NOT fully read
Validating file 0036.fff ... 0/0/0/121984 - NOT fully read
Validating file 0037.fff ... 0/0/0/32 - NOT fully read
Validating file 0038.fff ... 0/0/0/32 - NOT fully read
...
Validating file 0113.fff ... 0/2097152/0/0
Validating file 0114.fff ... 0/2097152/0/0
Validating file 0115.fff ... 161888/1935264/0/0
Validating file 0116.fff ... 1980224/96768/0/20160
Validating file 0117.fff ... 265824/52416/0/0
Data OK: 14.44 GB (30275959 sectors)
Data LOST: 13.77 GB (28874473 sectors)
Corrupted: 9.92 GB (20793321 sectors)
Slightly changed: 0.00 Byte (0 sectors)
Overwritten: 3.85 GB (8081152 sectors)
WARNING: Not all data was read due to I/O error(s)
Reading speed: 15.77 MB/s
The version 1.1.3, the current version, fixes some warning issued by GCC when compiling f3read.c on 64bits machines. Nicolai Abruzzese was the first one to report this issue. The outputs that he obtained were as follows:
f3read.c: In function 'report': f3read.c:126: warning: format '%llu' expects type 'long long unsigned int', but argument 5 has type 'uint64_t' f3read.c: In function 'iterate_path': f3read.c:166: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'uint64_t' f3read.c:166: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' f3read.c:166: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' f3read.c:166: warning: format '%llu' expects type 'long long unsigned int', but argument 5 has type 'uint64_t'
When Art Gibbens tested a flash card hosted in a camera connected to his Linux box, at some point F3 didn't show progress, and could not be killed. After a reboot, the card was read only. Using an adapter to connect his card directly to his machine, he recreated the partition of the card adapting the steps described in section "How to 'fix" a fake card', and successfully run F3 with the card in the adpater. Thus, Art's experience is a good warning if you're testing your card in a device other than an adapter. Please, don't take it as a bug of F3. I'm aware of only two things that can make a process "survive" a kill signal: hardware failure, and/or bug in the kernel. F3 doesn't run in kernel mode, so Art's camera is likely the root of the problem.