Date: Wed, 2 Dec 1998 10:56:53 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: FAT32X and DJGPP
In-Reply-To: <199812012257.XAA25275@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.981202105639.24125P-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com


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).