Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3EA530A7.C38FCB1A@phekda.freeserve.co.uk>
Date:	Tue, 22 Apr 2003 13:08:07 +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:	Eli Zaretskii <eliz AT elta DOT co DOT il>
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> <3EA2670B DOT C1014D39 AT phekda DOT freeserve DOT co DOT uk> <1190-Sun20Apr2003135401+0300-eliz AT elta DOT co DOT il> <3EA435FE DOT D15313E1 AT phekda DOT freeserve DOT co DOT uk> <9628-Tue22Apr2003103342+0300-eliz AT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Mon, 21 Apr 2003 19:18:38 +0100
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> > >
> > > If `fstat' supports UNCs, but `stat' does not, it is IMHO a bug that
> > > we ought to fix.
> >
> > I think 'stat' used to support UNCs. I recall testing it: when I was
> > working on unc_fsx, you pointed out that some library functions already
> > supported and UNCs and I believe stat was the one.
> 
> Perhaps I'm no longer familiar enough with the CVS code, but unless
> `stat' performs the same UNC-to-drive-letter mapping, it will generate
> an inode that is different from what `fstat' produces for the same
> file.  And that's the bug I was referring to.

Ah, OK. The fstat patch does not add the mapping code to 'stat'. I will fix
that in revision 4 of the patch.

But there seems to be another bug, which is the one I described. I am sure
that stat used to work on UNC filenames. Now it fails, because
__canonicalize_path mangles UNC path names. As an example, the case I played
with was \\iolanthe\zips\libtool-1.5.tar.gz. When the current working drive is
C:, __canonicalize_path converts this to c:/iolanthe/zips/libtool-1.5.tar.gz,
when it should be c:\\iolanthe/zips/libtool-1.5.tar.gz.

I have added a work item for the __canonicalize_path bug to the 2.04 status
page. It's priority 1 (fix before release) rather than priority 0 (a
showstopper), because I don't believe UNCs are used all that much with DJGPP.
If they were, the bug would have been surely noticed earlier.

> > > If the drive mappings are changed during the program's execution, I
> > > think the file descriptor is no longer valid.  Perhaps someone could
> > > try this and see whether I'm mistaken.
> >
> > Yes, it does. Below is t-unc.c. If you change the mapping while the
> > program is sleeping, the second filelength call will fail with errno ==
> > EINVAL.
> 
> Thanks for testing.  So this is not an issue, I think.

No, I don't think so.

The case I was concerned with is:

1. Map \\somemachine\someshare is mapped to x:, say.

2. Open the file \\somemachine\someshare\foo.txt.

3. fstat the file. The mapping cache contains X -> \\somemachine\someshare.
The UNC in the filename from fd_props is collapsed to x:/. The filename for
generating the inode is x:/foo.txt.

4. The mapping is changed by another process, so that y: maps to
\\somemachine\someshare.

5. fstat the file again, after the cache time-out period has passed. The
mapping cache now contains Y -> \\somemachine\someshare. The UNC in the
filename from fd_props is now collapsed to y:/. The filename for generating
the inode is now y:/foo.txt.

Steps 3 and 5 will return a different inode for the file.

The solution to this problem is to expand the drive letter to a UNC, when we
have the UNC. Please let me know, if you think I should implement it this way.

This problem may be moot, since the library doesn't support UNCs completely.
By "support" I mean that UNCs are not supported everywhere like "normal"
filenames.

Bye, Rich =]

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

- Raw text -