Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E2C5FEF.E9AC8D1C@phekda.freeserve.co.uk>
Date:	Mon, 20 Jan 2003 20:45:35 +0000
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:	djgpp-workers AT delorie DOT com
Subject:	Re: fstat, fd_props and inventing inodes [PATCH]
References:	<E18XkXR-0001ZC-00 AT phekda DOT freeserve DOT co DOT uk> <2593-Wed15Jan2003095337+0200-eliz AT is DOT elta DOT co DOT il> <3E2BFD47 DOT F2FCA284 AT phekda DOT freeserve DOT co DOT uk> <2427-Mon20Jan2003213728+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Mon, 20 Jan 2003 13:44:39 +0000
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> > >
> > > Did you try to see what does this do with (a) handles open on devices,
> > > and (b) redirected handles?
> >
> > Results for (a):
> [...]
> 
> Thanks for the footwork.  Looks like everything's okay, right?  Or do
> I miss something?

It looked fine to me. But I thought your eagle-eyes might spot something I
hadn't. ;)

> > > Also, if you run _fixpath on a file name in a place other than where
> > > the file is actually opened, the program might be in a different
> > > directory, so _fixpath will produce incorrect results.  Therefore, I
> > > believe that if we want to use fd_props for this, we should run
> > > _fixpath on the file name when its info is recorded in fd_props.
> > > Then fstat should simply reuse the absolute name.
> >
> > Well, it turns out that __set_fd_properties() runs the file name through
> > _truename(), before storing it. I think _truename() is sufficient - I
> > don't think we need to call _fixpath in fstat(). I think we can just use
> > whatever __get_fd_name() returns.
> 
> `_truename' might return a UNC, in which case you don't have a drive
> letter to determine the st_dev member of struct stat.  So if we do as
> you suggest, we need to handle this case inside `__set_fd_properties'.
> 
> Otherwise, this plan is okay with me.

I tried to think of reasons why _truename was preferred over _fixpath. AFAICS
_truename handles subst'd/assign'd/join'd drives, but _fixpath doesn't. That
seems like a good reason for keeping _truename and handling UNCs specially.

How do you think we should handle UNCs?

Should we just ignore UNCs?

Or should we scan through the list of shares that we have mapped, to determine
the drive letter? (I was assuming that _truename would return the drive letter
for a UNC with a mapped drive.)

Thanks, bye, Rich =]

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

- Raw text -