Mail Archives: djgpp/1998/12/29/15:17:17
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
- Raw text -