[bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: "PAMELA RADER" <PRADER@xxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Tue, 20 Sep 2005 15:21:05 -0400
Brian:
I'm sure our developers will appreciate this information. I, too, have
seen some of what you're describing with respect to files and flash
cards, so perhaps this will help us get to the bottom of this. When
reading Rusty's email, I suspected it was firmware related, rather than
a problem with his particular unit, but never thought the two things
could be connected. Now, we'll have to see what the chieves can
uncover.
Pamela Rader, TECHNICAL SUPPORT
American Printing House For The Blind
1839 Frankfort Ave.
Louisville, KY 40206
PHONE: 1-800-223-1839, Ext. 307
>>> buhrow@xxxxxxxxxxxxxxxxxxxxx 09/20/05 02:44PM >>>
Hello. Over the last week I have been researching this problem
further, and while I don't have a complete explanation, I do have some
more
data points.
The problem appears to crop up when index files are deleted
from
directories, including the root directory, on the Bookport. It seems
as
though Bookport ignores the fact that an index file might be deleted,
and
it tries to interpret the data in that deleted index file as if it were
an
index file. Since the data is most likely garbage, and there is
apparently
little error checking in the index reading routines in bookport, it
allocates RAM inside the Bookport based on the bad data. As a result,
Bookport's memory becomes corrupt, and access to subsequently read
material
becomes unpredictable. The corruption can happen silently, as
Bookport
processes Index files as you traverse files with the * and # keys. I
have
found that, sometimes, I get error messages like: "Error accessing
Index
file", in places where no index file should be, usually followed
shortly by
error messages like: "FS error: out of drobj structures," repeated
some
number of times, followed by the message: "Application file write
error".
Because the corruption pattern is undefined, however, you can't be sure
that
you're going to get error messages.
In no case have I found the Bookport corrupting the CF card
itself.
In fact, I have found that by pulling out the CF card, and reinserting
it
after one of these incidents, allows me to read the rest of the
material on
the CF card without incident, and with full navigational abilities.
In
Rusty's case, I suspect the extraction and reinsertion of the CF card
is
what allowed him to return to a "good" reading state. However, I
predict
that as he explores his CF card with the * and # keys, the corruption
will
return and the page numbers will again be incorrect. One contributing
factor, in Rusty's case, is the fact that he's using very large files
for
reading.
In summary, I think there may be two problems which are
contributing
to these vague experiences people are periodically reporting. Both of
these problems are combining to make the issue more confusing. The
good
news, I think, is that APH, or Springer -- as I think this is probably
springer code where the trouble is -- should be able to very quickly
determine if these two bugs, if they are bugs, are really there by
examining the source code to the Bookport firmware.
1. Bookport is not completely ignoring deleted index files in its
directory trees. (I do not know if it determines an "index" file
based
solely on the file extension, or if it uses a signature in the index
header, but if it uses the file extension, I could believe it might be
looking at the extensions of files without first checking to see
whether
those files are deleted.)
2. Bookport does not completely reinitialize the memory used for
processing index files when it switches from one index file to
another.
This bug alone could account for Rusty's behavior, and explains why
things
work most of the time, but are somewhat inconsistent.
I hope this helps find what ever problem this really is.
-Brian
Other related posts:
