[bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMWARE 2.X?
- From: buhrow@xxxxxxxxxxxxxxxxxxxxx (Brian Buhrow)
- To: bookport@xxxxxxxxxxxxx
- Date: Tue, 13 Sep 2005 12:52:02 -0700
Hello Rob. Yes, I wondered about the FAT16/32 possibility, and
figured that the 2GB limit was imposed by the FAT16 nature of the
filesystem, but wrote FAT32 because I couldn't remember at the moment I was
writing the message, what the exact size limitation FAT16 imposed.
As to the problem itself, I should have noted in my original message
that chkdsk does indeed run clean when this problem is encountered.
-Brian
On Sep 13, 3:44pm, "ROB MEREDITH" wrote:
} Subject: [bookport] Re: POSSIBLE FILESYSTEM HANDLING BUG IN BOOKPORT FIRMW
} 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
}
}
}
>-- End of excerpt from "ROB MEREDITH"
Other related posts:
