Date: Mon, 13 Aug 2001 16:56:57 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: acottrel AT ihug DOT com DOT au
Message-Id: <557-Mon13Aug2001165656+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <019701c123f9$6febae70$0a02a8c0@acceleron> (acottrel@ihug.com.au)
Subject: Re: Fw: Fstat.c patch
References: <00fe01c12311$92957890$0a02a8c0 AT acceleron> <4331-Mon13Aug2001125532+0300-eliz AT is DOT elta DOT co DOT il> <019701c123f9$6febae70$0a02a8c0 AT acceleron>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Mon, 13 Aug 2001 23:11:15 +1000
>
> 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).

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

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