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 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: <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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Eli Zaretskii wrote: > > > Date: Mon, 20 Jan 2003 13:44:39 +0000 > > From: Richard Dawe > > > > > > 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/ ]