[bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: buhrow@xxxxxxxxxxxxxxxxxxxxx (Brian Buhrow)
- To: bookport@xxxxxxxxxxxxx
- Date: Tue, 20 Sep 2005 11:44:46 -0700
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:
