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 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 CC: djgpp-workers AT delorie DOT com Subject: Re: fstat, fd_props and inventing inodes, revision 3 [PATCH] References: <003101c30704$8dbb1ea0$0100a8c0 AT acp42g> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 . > 01/01/2003 08:54 PM .. > 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/ ]