From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <199901021618.RAA08436@father.ludd.luth.se>
Subject: Re: FAT32X and DJGPP
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sat, 2 Jan 1999 17:18:30 +0100 (MET)
Cc: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To: <Pine.SUN.3.91.981230104806.21377I-100000@is> from Eli Zaretskii at "Dec 30, 98 10:48:59 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-workers AT delorie DOT com

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

(Well Linux behaves like the ugly duckling:
kant:~> df -T
Filesystem    Type 1024-blocks  Used Available Capacity Mounted on
nietzsche.dcd.se:/clients/kant
              nfs      63407   19170    40963     32%   /
/dev/hda1     msdos   256740  151460   105280     59%   /DOS/c
/dev/hda2     vfat    256772  166680    90092     65%   /DOS/c2
/dev/hda6     umsdos   714656  671616    43040     94%   /DOS/d
/dev/hda8     umsdos  2096160 1966304   129856     94%   /DOS/e
/dev/hda9     ext2     62187    1746    57230      3%   /boot
                   ^                              ^     ^
N. B. ------------/------------------------------/------|

Although there's nothing that says DJGPP must be like Linux.)

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

Hey some success. Here follows parts of the output of the c program
appended last. Worth to note is that C:, E: and F: are FAT32 drives,
while D: is a (ordinary) FAT (16). G: is a ramdrive. H: is a ZIP drive
with a disk in it. I: and S: are no drives (doesn't exist). P:, Q: and
T: are network drives. R: is a CDROM/DVD drive with a music CD in it.
No floppies in the A: drive, there's no B: drive.

Please try the program and see if it reports the right FAT file system.
(And yes I know it's hackish, including hick-ups.)

----- Parts of output from program starts. -----
flags = 0x3003, ax = 0x15.
A: -> 0.
flags = 0x3003, ax = 0x15.
B: -> 0.
flags = 0x3002, ax = 0x6900.
File systen type: 'FAT32   '.
(70, 65, 84, 51, 50, 32, 32, 32, )
C: -> 1.
flags = 0x3002, ax = 0x6900.
File systen type: 'FAT16   '.
(70, 65, 84, 49, 54, 32, 32, 32, )
D: -> 1.
flags = 0x3002, ax = 0x6900.
File systen type: 'FAT32   '.
(70, 65, 84, 51, 50, 32, 32, 32, )
E: -> 1.
flags = 0x3002, ax = 0x6900.
File systen type: 'FAT32   '.
(70, 65, 84, 51, 50, 32, 32, 32, )
F: -> 1.
flags = 0x3003, ax = 0x1.
G: -> 0.
flags = 0x3002, ax = 0x6900.
File systen type: 'FAT16   '.
(70, 65, 84, 49, 54, 32, 32, 32, )
H: -> 1.
flags = 0x3003, ax = 0xf.
I: -> 0.
[...]
P: -> 0.
flags = 0x3003, ax = 0x1.
Q: -> 0.
flags = 0x3002, ax = 0x6900.
File systen type: 'CDAUDIO '.
(67, 68, 65, 85, 68, 73, 79, 32, )
R: -> 1.
flags = 0x3003, ax = 0xf.
S: -> 0.
flags = 0x3003, ax = 0x1.
T: -> 0.
[...]
----- Parts of output from program ends. -----

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

Well, an interrupt and a strncmp should suffice. Is that expensive? Perhaps
we should/could cache it?


Right,

							MartinS

----- C program starts. -----
#include <go32.h>
#include <dpmi.h>
#include <stdio.h>

int
_is_fat32(const int i)
{
  char s[9] = {0};
  int n;
  __dpmi_regs r;

  r.x.ax = 0x6900;
  r.h.bl = i; /* drive number (1=A:) */
  r.h.bh = 0;
  r.x.ds = __tb >> 4;
  r.x.dx = __tb & 0x0f;
  __dpmi_int(0x21, &r);
  for(n = 0; n < 8; n++)
  {
    s[n] = _farpeekb( _dos_ds, __tb + 0x11 + n);
  }
  s[8] = 0;
  printf("flags = 0x%x, ax = 0x%x.\n", r.x.flags, r.x.ax);
  if( (r.x.flags & 1) == 0 )
  {
    printf("File systen type: '%s'.\n", s);
    printf("(");
    for(n = 0; n < 8; n++)
    {
      printf("%d, ", s[n]);
    }
    printf(")\n");

    return(1);
  }

  return 0;
}


int main(void)
{
  int ret;
  int i;

  for(i = 1; i < 33; i++)
  {
    ret = _is_fat32(i);
    printf("%c: -> %d.\n", 'A' - 1 + i, ret);
  }

  return(0);
}
----- C program ends. -----