Mail Archives: djgpp/1998/12/02/06:07:46
On Tue, 1 Dec 1998, Martin Str|mberg wrote:
> I voluteer to try to better the support of FAT32.
Thanks!
> Where in the RBIL should i look at?t
Search it all for "FAT32", there are really not too many instances
that it's mentioned.
Issues to be resolved for FAT32 support (besides modifying `statfs')
include:
- Detection of FAT32 volumes (detection code should not crash even
if invoked on CD-ROM, network drive, or some other strange
filesystem).
- `_open' should use function 6Ch for FAT32 drives, since only that
function allows to use offsets longer than 32 bits in lseek and
reading files larger than 2GB in `_write'. However, DOS 3.x
doesn't support function 6Ch, so `_open' should test for the DOS
version first.
Also be sure to look for other functions that open/create files by
calling DOS directly, and change the DOS function they use as
appropriate.
- xstat.c will probably need a change in the function that invents
inode numbers, since it currently assumes the maximum cluster
number on disk is 65535, which is no longer true with FAT32. A
simple change is to begin with 2^31 and go downwards, unless you
can make FAT32 report the true cluster numbers to you (see below).
- You probably cannot change the definition of off_t (to something
wider than 32 bits) easily without breaking too many things. So a
new function, like _llseek (a-la Linux) or something like that is
probably in order. I suggest to make sure _llseek falls back to
lseek with non-FAT32 drives, so that libc functions could use it
internally without too much logic involved.
And while at that, please see if the Int 21h call that is supposed to
return the starting cluster number of a file works on FAT32. (See the
function `_ioctl_get_first_cluster' on stat.c in the library sources.)
RBIL implies that it should work on any modern DOS version, but I was
unable to get it to work on DOS 5.0, 6.20, or 7.0 (it always fails).
- Raw text -