delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/04/20/05:38:26.1

Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3EA2670B.C1014D39@phekda.freeserve.co.uk>
Date: Sun, 20 Apr 2003 10:23:23 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
CC: djgpp-workers AT delorie DOT com
Subject: Re: fstat, fd_props and inventing inodes, revision 3 [PATCH]
References: <E196rAk-0007Mp-00 AT phekda DOT freeserve DOT co DOT uk> <003101c30704$8dbb1ea0$0100a8c0 AT acp42g>
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Andrew Cottrell wrote:
> 
> > Here's revision 3 of the patch to fstat, to make it use the filename
> > from fd_props to generate an inode number, when it can't obtain the inode
> > from the SFT.
> 
> The following is from an email that Richard sent me a few days ago:
> > If you have time, please test it out. The main difference over the
> previous
> > patch is that it should cope with UNC path names. E.g.:
> >
> >     fstat("x:/foo", ...)
> >     fstat("\\machine\share\foo", ...)
> >
> > should return the same results, when \\machine\share is mapped to x:.
> >
> I have applied the patch to my djgpp directory and I thought I would try out
> "ls" and comapre it against dir to see if the UNC code worked. I did find
> some discrepancies as indicated below. Are the results below expected or
> not?

They are expected. IIRC not all the DJGPP library functions support UNCs. The
fileutils code is not aware of UNCs. So 'ls' should not be expected to work
with UNCs.

fstat, however, does work on UNCs.

The patch makes fstat generate the inode number for a file based on the
filename from fd_props (plus some munging for UNCs). The filename in fd_props
is the result of running _truename on the filename used to open the file.
_truename apparently may not convert UNCs into the mapped drive letter.

So the point of the UNC code in the patch is to ensure that we use the same
name, whether the file is accessed through its mapped name (e.g.: x:/foo) or
its UNC name (\\machine\share\foo).

I suppose the patch may not work correctly, if the user opens the file using
the UNC, then maps it to a drive later. In that case fstat'ing before and
after the mapping will give different inodes. The same is true if the UNC
mapping is changed to a different drive letter. But I think it is unlikely in
practice that the mappings will change during the course of program execution.

> DJ204 D:\dj204\gnu\filutil4.1\src>dir \\ac-p42g\ghost
>  Volume in drive \\ac-p42g\ghost has no label.
>  Volume Serial Number is 3E10-A62B
> 
>  Directory of \\ac-p42g\ghost
> 
> 01/01/2003  08:54 PM    <DIR>          .
> 01/01/2003  08:54 PM    <DIR>          ..
> 06/01/2003  09:32 PM     2,147,465,827 C_06JAN2.GHO
> 03/01/2003  05:27 PM     2,147,461,465 C_DRIVE_.GHO
> 03/01/2003  05:27 PM       642,021,517 C_DRI001.GHS
> 06/01/2003  09:32 PM       404,498,931 C_06J001.GHS
>                4 File(s)  5,341,447,740 bytes
>                2 Dir(s)   1,550,123,008 bytes free
> 
> DJ204 D:\dj204\gnu\filutil4.1\src>ls \\ac-p42g\ghost
> ls: //ac-p42g/ghost: No such file or directory (ENOENT)

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019