[WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)
edorfaus at xepher.net
Sat Oct 31 19:27:51 CET 2009
On Saturday 31 October 2009 02:35:42 Sean Moss-Pultz wrote:
> On Sat, Oct 31, 2009 at 3:46 AM, Doug Jones <dj6mf at frombob.to> wrote:
> > (1) Has OpenMoko made the policy decision that filenames will be limited
> > to 8.3?
> We're using FAT.
I have a usable grasp of how FAT works, so I figured this would be the answer
while reading this thread, and thought I'd reply with an explanation even
before I saw your reply. It's not just policy, there are technical reasons.
While I suppose it's really enough to accept that this is how it is, I guess
people with less of a grasp on how FAT works might need an explanation to
really understand why this is the only sensible choice, so here goes:
The FAT filesystem inherently supports up to 8.3 filenames, and nothing more.
This is a limitation of the on-disk format used for directories (including the
Long file name (LFN) support has been implemented on top of this (aka VFAT) in
some systems, but it is really a hack: it adds extra directory entries that
are (iirc) marked as being deleted files, and then uses the rest of the data
(both filename and other fields, like size) for those entries to contain
characters representing the long filename for the following directory entry
(the real file). Thus, implementing this is a bit complex and hacky.
This is why DOS (and the DOS mode of W9x) doesn't see the long file names (just
foobar~1.ext), and might destroy the LFN if you do certain things with the
files (such as moving to another dir) - they were made before LFNs existed.
Besides, even with just 8.3, that's 11 bytes that can be chosen pretty much
arbitrarily (only a few values you can't use); for most purposes you don't
need even that, and can put conventions into place (such as using a specific
.ext for specific file types).
Personally, I see no reason why the wikireader should need more than 8.3
filenames, at least for the kernel to know what app to start, or the reader app
to find its data files.
> > (2) How complicated will it be to implement subdirectory support?
> Not a problem. We're going to do something like this when we support
> more languages.
That certainly seems like both the easiest and most sensible approach.
> > Note that only one subdirectory level is really needed to implement what
> > has already been suggested.
This is kind of interesting in a way. The first DOS versions (that supported
directories at all) only supported one level. :)
> > We could adopt a brain-swap approach: After bootup, the user selects
> > one wiki and then the app switches to the selected subdirectory and
> > considers that to be the root until the next cold boot. All 81 files
> > kernel.elf. Only the initial wiki selection app (we would have to write
> > one) would have to understand subdirectories, and only to one level deep.
> Yeah that should work.
I thought of the same, and afaik there's just one small gotcha (not really a
problem though): subdirectories are not quite the same on-disk as the root
The format of the data in the directories is the same, sure. But
subdirectories are stored the same way files are - in a chain of clusters -
while the root directory is a specific area on the disk, determined at FS
creation time. This is why the root directory has a limited number of files it
can hold, while subdirectories don't.
So, the code reading the directory entries from the disk still has to know if
it's reading the root dir or a subdirectory, to know where on the disk to load
the entries from. The code parsing those entries can be the same though.
One way to simplify this could be to *always* keep apps such as the wikireader
in a subdirectory, never in the root directory, as then only the app selector
needs to know how to read the root dir.
Of course, if the filesystem reading/parsing code is provided by the kernel, as
a service to the programs, it could take care of this (rather small) difference
under the hood, without each app having to deal with it on its own - that
seems much more sensible to me, since it needs to know how to read FAT anyway.
That could also open up another intriguing possibility... Copying the app
selector into a subdir that has subdirs of its own. From the POV of any app
that doesn't understand directories, it doesn't really matter how deep it is,
and even if it does understand them, it still doesn't matter as long as the
current directory is considered the root and the .. directory is ignored.
Then, if the selector was implemented so that it could switch root to the ..
directory and (re)start that app, you could even move up again in the tree...
Well, this all assumes the "root" subdir selection is done by keeping the
cluster number or some such (as opposed to keeping the path by name).
More information about the community