Messages like "Removing old file 0001.fff ..." were issued in
a file system dependent order.
This is a cosmetic change that takes advantage of
the function ls_my_files previously created for f3read.
If an F3 file (i.e. *.fff) but the last one is missing,
f3read will report the missing file with a warning similar to this one:
Missing file 0001.fff
AND the following warning will be presented at the end of the report:
WARNING: Not all F3 files are available
Kenneth Arnold suggested this feature in an e-mail:
"I also noticed that if one of the files is completely missing, f3read
will still report no errors. The chance that this will happen on its
own without messing something else up is too small to worry about,
except possibly in the case that the device was actually read-only and
no files actually got created. In that case, f3read succeeds with 0
sectors OK and 0 sectors lost."
The last F3 file, if missing, is not reported because
it can be confusing.
The following example gives an idea of the problem:
a memory card wasn't empty when f3write was called and
the last F3 file created was 0010.fff with exactly 1GB;
here none F3 file is missing.
Then, some non-F3 files were removed, and f3read is called.
f3read would report a missing file even when non-F3 files were
removed!
The problem gets a little bit uglier if 0010.fff in the example
is less that 1GB, or the file system doesn't let f3write to
fill it up for a few bytes (this should be very rare, but
there's no guarantee that it cannot happen).
Finally, the implementation of this feature has a positive
side effect: f3read processes F3 files in ascending order,
that is, 0001.fff, 0002.fff, ..., NNNN.fff.
Before the order was file system dependent.
Magic numbers related to the number of digits in the F3 files'
names were eliminated.
See file Documentation/CodingStyle in Linux's source code
for a reference of the style.
Used "indent -kr -i8" to help out.
Added a .gitignore to the repository.
