[bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: "ROB MEREDITH" <rmeredith@xxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Tue, 13 Sep 2005 15:44:57 -0400
Brian:
Interesting, though the file system is currently FAT16, not FAT32.
The way to test your hypothesis is relatively straight forward. If
chkdsk reports the file system as being free of errors, but the Book
Port still has trouble with the card, you may be on to something.
Generally when users have problems, they also have a corrupt file
system, and reformatting fixes both the file system and fragmentation at
once.
Rob Meredith
>>> buhrow@xxxxxxxxxxxxxxxxxxxxx 09/13/05 03:36PM >>>
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: