[bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: buhrow@xxxxxxxxxxxxxxxxxxxxx (Brian Buhrow)
- To: bookport@xxxxxxxxxxxxx
- Date: Thu, 13 Oct 2005 03:22:34 -0700
It's been a while since anyone has written on this topic, but I
believe I have more data points to throw into the frey, and a suggested
change to the Bookport firmware which might make the problem more obvious,
and thus avoidable.
In my previous message, I said the problem appeared to have to do with
the bookport interpreting deleted files as index files and thereby
corrupting its internal memory as part of that process. I now believe this
behavior is restricted to the root directory of the current CF card, and,
specifically, when the root directory is nearly full.
For those of you who don't know, I'll fill in some details that I hope
will make things more clear. Microsoft, when they designed the FAT16
filesystem, made the root directory a fixed size. The root directory of a
FAT16 filesystem cannot contain more than 512 file names of 8,3 in length.
When they released Windows 95, and added long file name support to the
FAT16 filesystem, they did it by writing the longer file names in
consecutive directory slots preceeding the base 8,3 filename. Thus, any
file name longer than 8,3 in length in a FAT16 filesystem uses at least two
directory slots, and most likely, it uses more. Given the 512 slot
restriction of the FAT16 filesystem, it is only possible to put, at most,
255 file names in the root directory of a FAT16 filesystem, assuming those
file names fit in just two directory slots each. I realize the
mathematically astute will note that half of 512 is 256, but I forgot to
mention that one of the 512 slots is taken up with the FAT16 volume label,
leaving only 511 slots available for actual use.
The bookport typically has three files associated with each "book" on
its flash card. The ._IX file contains the navigational data necessary to
move around the book, the ._DD file contains the actual data contained in
the book, and the ._AA file contains a place holder which is updated, or
created, as the case may be, when ever the user accesses the associated
book.
Given this information, we now have, a root directory which can
contain, at most, 255 file names. If we divide 255 by 3, we get 85, which
is the maximum number of books you could possibly fit in the root directory
of a CF card, assuming the file names were long enough to qualify as long
names, and short enough not to consume more than 2 directory entries each.
If you only load MP3 files onto your Bookport, and you don't do it through
the transfer utility, you could, in theory get 127 items onto your root
directory, because while you wouldn't have an ._IX file, you would still
have a ._AA file associated with each item, and 255/2 is 127.
The bug in Bookport, I believe, is that it doesn't handle a full root
directory condition in a manner which could be considered graceful under
any circumstance. Since the bookport creates its place holder files when
ever the user accesses a file on its CF card in the same directory where
the file resides, it is possible, and probable, that the root directory
could fill in the middle of a place holder creation process. Since the
Bookport doesn't check to see if it has enough space to create a new file
before it starts the creation process, it could run out of space at a
number of points in the creation process. Worse, it could leave the
directory in a state which is perfectly readable by your Windows machine,
but which the Bookport itself can't properly understand.
I believe Windows itself will properly notify users when a FAT16 root
directory is full, meaning the Transfer Utility will properly report a disk
full condition before scribbling needlessly in the root directory. Thus,
no change needs to be made there.
Bookport, on the other hand, should fail more gracefully when this
happens. What I would like to suggest, and folks are free to debate this,
is that if a user accesses a file in the root directory for which no ._AA
file exists, and a new ._AA file cannot be created because it would
overflow the root directory, Bookport should say something like:
"Unable to create book marker, too many files in root directory."
In addition, I think Bookport should, for the root directory of CF
cards, issue a warning that the root directory is getting full when the
total number of directory slots in use is 90% or greater.
I do not know if the bookport transfer utility can provide the same
warning, I suspect it cannot, because it doesn't access the CF card at that
level in the OS, but it could certainly be modified to provide similar
functionality through examination of the root directory's contents.
I consider this bug a fairly serious one, because it manifests itself
in so many different ways, and because it requires a trip back to the
bookport transfer utility and the host computer to fix it, once it is
encountered. Bookport should not corrupt the filesystem it uses to store
its book markers, and any bug which causes this to happen, is, in my view,
serious.
I do not know if this bug is triggered all of the time when the root
directory fills up, but I suspect Bookport becomes pretty darned flaky when
this happens.
I hope this description sheds more light on the issue, and, if I'm
completely off base, please, someone tell me. :)
-Brian
Other related posts:
