X-Authentication-Warning: new-smtp1.ihug.com.au: Host p273-tnt2.syd.ihug.com.au [203.173.131.19] claimed to be acceleron
Message-ID: <028c01c12405$d1b326e0$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>, "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
References: <00fe01c12311$92957890$0a02a8c0 AT acceleron> <4331-Mon13Aug2001125532+0300-eliz AT is DOT elta DOT co DOT il> <019701c123f9$6febae70$0a02a8c0 AT acceleron> <557-Mon13Aug2001165656+0300-eliz AT is DOT elta DOT co DOT il>
Subject: Re: Fw: Fstat.c patch
Date: Tue, 14 Aug 2001 00:39:53 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Reply-To: djgpp-workers AT delorie DOT com

> > The link problem is that the existing code fails on the following if
> > condition as one of the stat buffers is from stat() and the other is
from
> > fstat().
> >   if (statbuf1.st_dev != statbuf2.st_dev)
> >   {
> >     (void)close(fd1);
> >     (void)close(fd2);
> >     (void)unlink(path2);
> >     errno = EXDEV;
> >     return -1;
> >   }
>
> The st_dev stuff comes from fstat, so the key for the problem is
> there.
>
> I think this happens because, as Charles reported earlier,
> _get_dev_info always returns zero for LFN handles, so all files look
> as if they were on drive A:.
>
> If I'm right, setting LFN=n should cure this problem (of course, this
> is not the solution I propose for the library, just something to test).
No the solution that I found worked was to change the stat() calls to
fstat() calls and the code in link.c then works. If this sounds okay then I
can produce a patch tomorrow night. It's 12:30 AM at the moment.

> > The flaw in the existing fstat() code is that the dos_major vaiable is
not
> > setup on Win 98 with LFN enabled.
>
> Hmm?  Are you sure?  Could you please step with a debugger into fstat
> and see why doesn't dos_major get set?  I've just tried that on my
> Windows 98 system, and dos_major's value was 7.
I put a printf before the check and it printed 0.  I will do this tomorrow
night.  I suspect that the following code did not call get_sft_entry(). I
will check this tomorrow night.

  /* Get pointer to an SFT entry which holds data for our handle. */
  if ( (_djstat_flags & _STAT_NEEDS_SFT) == 0 &&
       (sft_idx = get_sft_entry(fhandle)) == -1)
    {
      errno = EBADF;
      return -1;
    }

> > The following code is the original code
> > and is not executed on Win 98 with LFN enabled, got caught by wrong
> > comments. My test app was CP from the file utils.
>
> I tried this with the simple test program produced from fstat.c if it
> is compiled with -DTEST.
>
> >                   r.x.ax = 0x71a6;      /* file info by handle */
> >                   r.x.bx = fhandle;
> >                   r.x.ds = __tb >> 4;
> >                   r.x.dx = 0;
> >                   __dpmi_int(0x21, &r);
> >                   if ((r.x.flags & 1) == 0
> >                        && (_farpeekl(dos_mem_base, __tb) & 0x07) == 0)
> >                   stat_buf->st_mode |= WRITE_ACCESS; /* no R, S or H
bits set */
>
> It might be a good idea to look into the file attributes returned by
> 71A6: perhaps there's some indication of the drive letter there (my
> references are silent about all but the low 6 bits of that DWORD.

Will look at this tomorrow night.