[bookport] POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: buhrow@xxxxxxxxxxxxxxxxxxxxx (Brian Buhrow)
- To: bookport@xxxxxxxxxxxxxxxxxxxxxxx
- Date: Tue, 13 Sep 2005 12:29:30 -0700
Hello. Let me appologize in advance if this message is not completely
well formed. I'm still working out the details of what I think might be a
filesystem handling bug in the Bookport firmware, versions 2.x. It might
exist in the 1.x versions of firmware as well, but I can't test that.
A number of users on this list have complained recently that they have
gotten strange error messages when they've tried to access files that
they've transfered to their Bookports. When they recopy the data to their
Bookports, all is well. I too have experienced something like this, and believe
I have an understanding of where the problem is, and a possible work
around.
The Bookport uses flash cards formatted with the FAT32 filesystem, the
traditional "MS-DOS" filesystem which has been used, with little
modification by OS's from Microsoft since DOS 2.x. You might say it has
become the de facto lingua franca for portably allowing non-Windows devices
to interoperate with the Windows operating system. (Windows now uses NTFS
by default, but it continues to support the FAT16 and FAT32 filesystem
formats, and many people continue to choose to use this format, precisely
because it is understood by so many different devices and fixit programs.)
As part of its operation, Bookport writes little"placeholder" files on
the flash card, which it uses to "remember" where you were in a file, and
which file you were last reading. These files are updated when ever you do
things like press the reading key to stop and start the Bookport, or press
the * and # keys to select a new file to read.
When files are deleted from the FAT32 filesystem, the first character
of their names are changed to a "?", and the blocks associated with their
contents are marked as free. When new files are added, their names are
filled in in the first available location in the directory in which the
file is placed. This slot can either be a completely unused slot, i.e. one
which has never been used before, or it can be one which was previously
used by a now deleted file. As time goes by, and a filesystem is used more
and more, the number of free directory entries which contain the remains of
former files goes up and up.
What I have found is that if I add files to the Bookport, then delete
different files from the Bookport, the likelihood that I will be unable to
access one or more of the files I added when the Bookport is disconnected
from the host computer goes up. On the other hand, if I first make my
deletions, then add my files, I can be reasonably sure all will work fine.
This is where I become somewhat confused. My Theory is that Bookport
does not like a lot of gaps in its directories. When it tries to create
its placeholder file the first time a user accesses a newly added file in
stand-alone mode, it becomes confused about where it should place the file
in the directory. When this happens to me, I get the message: FS write
error, unable to allocate P R O J structures, repeated three times, folowed
by the message: application write error. Sometimes with MP3 files, I get
the message: Audio file read error.
My guess is that this problem is related to the problem Linette has
been having, although she has been getting different error messages. But
then, she's running a newer version of firmware than I am, and it could be
that that makes a difference too.
So, to summarize, I believe there may be a problem in the Bookport's
onboard filesystem code, where if a user adds a bunch of files to a flash
card, then deletes some files, some of the newly added files will be
inaccessible to the Bookport once it is running in stand-alone mode. I
believe this can be worked around by assuring that if a user makes any
deletions desired from the card before adding things to the card. However,
if this really is a bug with the filesystem handling code in the Bookport,
then it should be found and fixed, or, over time, every flash card that
gets used by active readers, will eventually display this behavior so
often, that users will be forced to reformat their flash cards regularly to
get them working again.
If I'm completely off base here, please let me know.
-Brian
Other related posts:
