From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: fstat works incorrectly under Windows NT Date: Thu, 06 Apr 2000 21:27:49 +0200 Organization: NetVision Israel Lines: 47 Message-ID: <38ECE535.D0414969@is.elta.co.il> References: <8chqb5$78u$1 AT sunsite DOT icm DOT edu DOT pl> NNTP-Posting-Host: ras1-p19.rvt.netvision.net.il Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.netvision.net.il 955049191 11535 62.0.172.21 (6 Apr 2000 19:26:31 GMT) X-Complaints-To: abuse AT netvision DOT net DOT il NNTP-Posting-Date: 6 Apr 2000 19:26:31 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,ru,hebrew To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Wojciech Galazka wrote: > > Under Windows NT the command 'ln a b' cannot produce a hard link from a file > 'a' to a file 'b'. Question no.1: did you compile `ln' yourself, or are you using the binary from fil316b.zip on SimTel? (That binary was compiled with DJGPP v2.01; `fstat' changed since then.) > A close inspection of the ln.c soiurce shows that the problem is in > libc/posix/unistd/link.c. > link() call doesn't work because the call fstat(destination file) (in this > case file 'b') returns > 0 in the st_dev field of statbuf struct instead of 3 (the file is on drive > d:). Question no.2: with what version of DJGPP did you test this? > 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? > 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. > [SFT ] which > Windows NT does not to fill correctly for a newly created file. > All I could think of this for now is to manually 'update' the SFT table > while creating the file. 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. If there is a valid SFT, `fstat' could be changed to use its info. Please tell what should be changed in `fstat' so that it believes the NT emulation of the SFT.