Whether or not the discussed bug exists, the root directory
limitation does. Given that and your statement that a lot of BP
users are ignorant about folders, a modification of Chris hill's
suggestion could have saved a lot of grief.
You could force the use of a single sub-directory called BP. Both
the BookPort and the transfer software could be set so that the user
could not back out of this directory.
At 08:30 AM 10/13/2005, you wrote:
This could be a serious bug, and we want to fix it if it is, but your suggestion to not do that is a good one if the user actually knows what is going on. I'm afraid, however, that there are a lot of new Book Port users who don't even know about folders yet.
>>> dljustice@xxxxxxxx Thursday, October 13, 2005 8:24:29 AM >>> Your message reminded me of an old joke ... "Doctor doctor it hurts when I do this ..."
Now I am indeed not making light of the problem, but the punch line in either case is the same -- don't do that.
If the problem occurs only if one places too many files in the root directory, then place folders (A.K.A. sub-directories) in the root directory instead. Doing thus, you not only would avoid the stated problem, you could better organize the contents of your flash card and make accessing that content easier.
I am not saying that the problem need not be fixed, but if it manifests itself only under the conditions you have stated, then it need not be encountered.
At 06:22 AM 10/13/2005, you wrote: > 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
