Mail Archives: djgpp-workers/2001/08/13/09:58:24
> 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.
- Raw text -