Brian Chu


I'm working on the msdosfs driver for Summer of Code 2007, and am being mentored by KonstantinBelousov.

TODO List, Ordered by Priority

The following are snippets that Konstantin has managed to gather for me about my project.

msdsofs has been broken since Giant locking for file systems (or syscalls)
was removed.  It allows multiple threads to race accessing the shared
static buffer `nambuf' and related variables.  This causes remarkably
few problems.  One case that breaks reliably is concurrent tars or finds,
especially with a small cluster size, even on a UP system.  Then
getdirentries() returns garbage entries and/or lookup() of correct entries
can't find things.  On my UP system, I think the race occurs mainly when
getdirentries() blocks on i/o and a directory entry spans the block
boundary.  Then another getdirentries() or lookup() can run, and if it
does then it will almost certainly corrupt the state for the blocked
getdirentries().  On SMP systems, I think the race occurs much more often
and suspect that it is more harmful.

Quick fix for an old version of FreeBSD. The part in msdosfs_lookup.c
has not been tested at runtime.  The part in msdosfs_vnops.c may also
fix bugs involving cookie handling (but not a memory leak like I first
thought?).  msdosfs_lookup.c is harder to fix because it has no common
cleanup code.


Please fix this better.  mbnambuf_init() could return a non-static buffer
that doesn't require locking.  Deallocation would be painful.  Note that
even the details for Giant locking can't be hidden in msdosfs_conv.c like
the current interfaces intend, since mbnambuf_init() is used a lot to
reinitialize an in-use buffer, and there is no interface to drop usage.

It turns out that quite a bit of our historical sanity checking on msdosfs is
too conservative when applied to the highly diverse set of FAT file systems in
the field.  I think it would be useful for someone(tm) to compare the sanity
checks in our version of msdosfs and the checks in the Darwin version and see
what they've had to remove.


OS/2 supports Extended Attributes (EAs) in the FAT filesystem, as well as in the HPFS file system. EAs can be composed of up to 64 KB of data relatied to the file. Because of the potential size of these EAs, they cannot be stored in a file's directory entry.

OS/2 uses reserved space in each file's directory entry to contain pointers to the EAs. The EAs themselves are stored in your root directory in a file called EA_DATA_SF, which has Hidden, System, and Read Only attributes. Note that the file EA_DATA_SF has two blank spaces represented here by the underscore characters (_) for clarity. DOS and DOS applications do not recognize filenames with embedded blank spaces because the blank is not a valid file-name character in DOS. The blank character is a valid filename in OS/2, however, even on a FAT drive.

More details:

Tasks needing review

> I have en ancient entry in my TODO list that says that we have
> the FAT filesystem data structures defined three places in our
> source tree, and that one should be enough.
> For the life of me, I can't remember what the third place is,
> but the first two must be:
>         fsck_msdosfs
>         sys/fs/msdosfs
> For some reason, I think mksdos_fs is not the third one, it could
> possibly be geom_label, but I'm not sure.


BrianChu (last edited 2021-03-28T10:20:00+0000 by KubilayKocak)