Date: Wed, 19 Mar 1997 12:29:28 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Dan Hirschberg <dan AT verity DOT ICS DOT UCI DOT EDU>
cc: djgpp AT delorie DOT com
Subject: Re: novice errors? dpmi, info, groff, df 
In-Reply-To: <9703181723.aa06452@paris.ics.uci.edu>
Message-ID: <Pine.SUN.3.91.970319122722.19845B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 18 Mar 1997, Dan Hirschberg wrote:

> *******************
> changing a: to c: and running the program
> *******************
> 
> SUCCESS
> type=0
> bsize=32768
> bfree=31249
> bavail=31249
> files=31249
> ffree=31249

Seems like a bug in NT DOS box (32768 * 31249 is NOT 2GB).  In case
you have motivation and time to investigate further, I attach below
the source of `statfs' from the library; please see if the values
returned in the registers by the call to Int 21h/AH=36h are indeed
erroneous in the case of the hard drive (it might be that the values
are OK, but the arithmetics makes them overflow).

Btw, what does "CHKDSK C:" report on that DOS box?  It should print the
values of BSIZE, FILES and BFREE as above (it does for me on MSDOS machine
with a 1GB disk).  And df works for me on Windows 3.11 for a 1.9GB
NFS-mounted disk. 

> *******************
> running df c:/
> *******************
> c:/djgpp/bin/df: cannot find mount point for c:/
> 
> *******************
> running df
> *******************
> 
> Filesystem         1024-blocks  Used Available Capacity Mounted on
> Drive A:                 713     450      263     63%   a:/
> c:\                   999968       0   999968      0%   c:/
> c:/djgpp/bin/df: d:/: No such device (ENODEV)
> c:/djgpp/bin/df: ?@: No such file or directory (ENODEV)
> c:/djgpp/bin/df: ??????????: No such file or directory (ENODEV)

These all seem to be caused by some problem inside `getmntent'
library function, which is probably unrelated to the problem with
`statfs'.  `getmntent' uses some low-level DOS calls to get all the
info that is expected from it, and it seems that some of its
techniques fail on NT.  If you could step into `getmntent' (I can send
you the source if you don't have djlsr201.zip) and see what exactly
goes wrong, I probably could figure out the solution.  Sorry, I don't
have access to NT.  And thanks for your efforts.

> It seems to me (but I really am a novice, so don't pay too much attention)
> that the system ought to first look for a long name matching
> the given name (here, tmac.pspic) and, if it fails to find it,
> secondly look for the truncated name (here, tmac.psp).

This will not work on NT, because DOS programs cannot see the long
filenames there.  The long filenames that you see on NT are only
available to native Win32 apps, so DJGPP programs can't access them;
they only see the short 8+3 names.  This would be OK, except that when
you unzip long filenames, NT adds a numeric tail to them, so
`tmac.pspic' produces something like `tmac~1.psp' rather than
`tmac.psp'.

> That would make the system consistent with an OS that has long names
> and also with an OS that has only 8.3 compliant names.
> Unzipping files that have long names should result in the long
> names being preserved because, first, other software may look for
> the long name and, second, there could easily be name conflicts
> if the original files have similar names (such as myprog.txt1
> and myprog.txt2).

This is how it works on Windows 95 which lets DOS programs see long
filenames via a special API (which is built into DJGPP low-level
library functions).  But NT doesn't support that API.

---------------------- statfs.c ----------------------------------
/* Copyright (C) 1995 DJ Delorie, see COPYING.DJ for details */
#include <dpmi.h>
#include <errno.h>
#include <sys/vfs.h>
#include <ctype.h>

int
statfs(const char *path, struct statfs *buf)
{
  __dpmi_regs regs;
  int drive_number;

  /* Get the drive number */
  if (isalpha(path[0]) && path[1] == ':')
    drive_number = (path[0] & 0x1f) - 1;
  else
  {
    regs.h.ah = 0x19;
    __dpmi_int(0x21, &regs);
    drive_number = regs.h.al;
  }

  /* Get free space info */
  regs.h.ah = 0x36;		/* DOS Get Free Disk Space call */
  regs.h.dl = drive_number + 1;
  __dpmi_int(0x21, &regs);

  /* Check for errors */
  if ((regs.x.ax & 0xffff) == 0xffff)
  {
    errno = ENODEV;
    return -1;
  }

  /* Fill in the structure */
  buf->f_bavail = regs.x.bx;
  buf->f_bfree = regs.x.bx;
  buf->f_blocks = regs.x.dx;
  buf->f_bsize = regs.x.cx * regs.x.ax;
  buf->f_ffree = regs.x.bx;
  buf->f_files = regs.x.dx;
  buf->f_type = 0;
  buf->f_fsid[0] = drive_number;
  buf->f_fsid[1] = MOUNT_UFS;
  buf->f_magic = FS_MAGIC;

  return 0;
}