Mail Archives: djgpp/2000/04/07/15:00:55
Eli Zaretskii wrote in a message: <38ECE535 DOT D0414969 AT is DOT elta DOT co DOT il>...
>Question no.1: did you compile `ln' yourself, or are you using the binary
>from fil316b.zip on SimTel?
>Question no.2: with what version of DJGPP did you test this?
At first I used a binary version then used that one compiled myself with
DJGPP 2.01
Sounds that I need to upgrade, though
>> Consequently the code snippet from link.cpasted below fails
>>
>> /* Fail if path1 and path2 are on different devices */
>> if (fstat(fd2, &statbuf2) < 0) return -1;
>> if (statbuf1.st_dev != statbuf2.st_dev)
>
>Question no.3: if `fstat' returns 0 for st_dev, and if it does that for
both
>files, then the above snippet should succeed, right? So what exactly is
the
>problem?
For an already existing file the return for st_dev is 3 (dirve d:) but for a
newly created file the result is 0 so the code fails. The new file was
created within ln.c code using Win32 call, and not int 21h, AH=6C call
hovewer
>
>> Fstat itself grabs the information for st_dev field from SFT table
>
>No. On NT, `fstat' is supposed to get st_dev from the IOCTL call issued by
>the function _get_dev_info; the SFT is not used on NT because NT doesn't
>emulate it. Please step with a debugger into `fstat' and see whether that
>this is what happens, or perhaps there's some bug.
>
>Are you sure NT indeed creates the SFT in its DOS box? AFAIK, it doesn't.
>That's why `fstat' doesn't use it: `fstat' has built-in sanity checks for
the
>data in the SFT, which AFAIK fail on NT.
Well, I stopped debugginf the codes on link() function. I'll bring the
debugger once more to see how fstast() really works. I'm not sure if fstat
uses SFT, and it's the first thing I'll check.
Thanks for you suggestions
- Raw text -