Mail Archives: djgpp-workers/1998/12/30/03:48:31
Note that I've redirected this to djgpp-workers.
On Tue, 29 Dec 1998, Martin Str|mberg wrote:
> Hmm. Should we improve the "Type" field from {hd,fd,cdrom} to {FAT12,
> FAT16, FAT32, ISOFS, ...}? Or will this cause to much rework?
There's nothing magic about these names, a discussion held during
development of the current version of mntent.c concluded that there's
no standard that says what should the TYPE field be. So I picked the
ones a PC user will understand. For example, ISOFS or even CDFS
(which is what Unix systems return) will probably be less obvious.
Therefore, there should be no problem to change these names, but I
think we should keep them at 5 letters or less, since otherwise the
report printed by `df' gets ugly.
One problem with FAT16 types of name is that they don't tell what kind
of drive is that, whereas "fd" and "hd" do (I think "floppy" is better
than "fd", but it's longer than 5 letters).
> It seems I can't find how to detect FAT32 (vs. FAT16) from RBIL (Ralf
> Brown's Interrupt List). Any ideas?
This is one of the problems that should be solved. We had a
discussion about this some time ago on djgpp-workers (search the
djgpp-workers mail archives for the subject "Should size_t become
unsigned"), and as far as I remember, two possible solutions popped
up:
- read the boot sector where the size of the FAT is recorded;
- use an FCB-oriented file function which doesn't work with
FAT32.
Personally, I like the latter solution better, even though I'm told
that the former one doesn't require to lock the volume (Windows 9X
requires to lock the volume, which is a very slow and anti-social
operation, for direct disk access, but only for writes, not for
reads).
However, the solution to this problem has never been finalized IIRC,
so it might well be there are other possibilities as well.
In particular, it remains to be seen how expensive the FAT32 detection
is. For `statfs' calls this problem might not be too important (how
many times do you call it in a program, anyway?), but if we are to use
FAT32-specific features in lseek and write, then it better be fast.
> From RBIL it seems it's only possible to seek using the old seek call
> (I can't find any FAT32 seek).
There is none, AFAIK.
> This means 2^31 per seek operation. Is this so?
Yes.
> I suppose the workaround is to let _llseek do several seeks
> to fullfill the seek operation.
Yes, that seems to be the only way.
> > 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)?
I suspect there's either something incorrect in RBIL, or some subtle
point in how that call should be issued that isn't described. I tried
some time ago to write to Ralf Brown and ask him about this call, but
got no response. Maybe you could try asking him again? It's a pity
that such a promising service cannot be used by DJGPP.
- Raw text -