Mail Archives: djgpp/1996/03/21/14:22:37
Eli Zaretskii wrote:
>
> On Thu, 14 Mar 1996, Thomas Demmer wrote:
>
> > Maybe this sheds a little light on the problem:
> > A stat() shows no difference between a local and a Netwarefile, except
> > that the inode is 65536+. _djstat_describe_lossage() says that a
> > starting cluster couldn't be found and stat hashes (although counting
> > upwards isn't exactly hashing ;-)
>
> It doesn't return the hash value, it uses the hash value to find whether
> an inode for this file was already generated, and if so, returns the same
> inode number as before; else it generates a new inode.
OK, I was confused by a comment in the source that several stat()s on one
file might return different inodes.
>
> > _truename("i:/demmer/plan",s) yields "\\brain1\usr\home\demmer\plan",
> > the filename in UNC.
> > A stat() in the file "usr:home/demmer/plan" (NetWare convention) makes
>
> You should never call `stat' with such non-DOS filenames. Don't expect
> them to work.
>
> > _djstat_describe_lossage() report the error "Cannot find SDA entry"
> > and gives a wrong device number, but otherwise the entries are correct.
>
> Which device number is that? Is it -2? If so, it might mean that some
> library function checks for the negative device number, or constructs a
> drive letter from the drive number and expects it to be an alphabetic
> character (a-z). Novell IPX (which, unlike NFS, doesn't use the DOS
> network redirector interface, but hooks Int 21h directly instead) is
> notorious for not returning some of the info `stat' should return.
No, the device number is the one of the current drive.
>
> > On the other hand, stat()ing a file on an NFS drive gives a hashed
> > inode, but _truename returns just the drive and the name.
>
> The string returned by `_truename' depends entirely on the network
> redirector. Some return UNC, others don't bother.
So, if stat() keeps track of files, why not extend it in such a way that it also keeps
track of visited servers? Redirectors that return a valid drive number like XFS
are treated like ordinary (local) drives. For beasts like NetWare one could invent
drive numbers, for example 32 and above. NetWare sometimes uses temporary drive
letters like [:, so one shouldn't use them.
I just found one difference between NETX and VLM: NETX gives the error message
described above. With VLM I just get the message "Failed to get starting cluster
number...". That might explain why gcc doesn't work with NETX but work's fine with
VLMs.
--
Ciao
Tom
*************************************************************
* Thomas Demmer *
* Lehrstuhl fuer Stroemungsmechanik *
* Ruhr-Uni-Bochum *
* Universitaetsstr. 150 *
* D-44780 Bochum *
* Tel: +49 234 700 6434 *
* Fax: +49 234 709 4162 *
* http://www.lstm.ruhr-uni-bochum.de/~demmer *
*************************************************************
- Raw text -