From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199812292017.VAA06409@father.ludd.luth.se>
Subject: Re: FAT32X and DJGPP
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Tue, 29 Dec 1998 21:17:04 +0100 (MET)
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.981202105639.24125P-100000@is> from Eli Zaretskii at "Dec 2, 98 10:56:53 am"
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

According to Eli Zaretskii:
> 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).

Hmm. Should we improve the "Type" field from {hd,fd,cdrom} to {FAT12,
FAT16, FAT32, ISOFS, ...}? Or will this cause to much rework?

It seems I can't find how to detect FAT32 (vs. FAT16) from RBIL (Ralf
Brown's Interrupt List). Any ideas?

>   - `_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.

I'll tackle statfs first...

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

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.

From RBIL it seems it's only possible to seek using the old seek call
(I can't find any FAT32 seek). This means 2^31 per seek operation. Is
this so? I suppose the workaround is to let _llseek do several seeks
to fullfill the seek operation. Any other ideas?

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

I can't get anything else than fail from _ioctl_get_first_cluster() or
the underlying dpmi_int() calls. Is RBIL correct (perhaps some typo or
something)? Has anybody gotten INT21, AX=0x440D, CX=0x871 to work?


Holmboe, Symphony No. 5,

							MartinS