Date: Tue, 14 Aug 2001 19:58:30 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: sandmann AT clio DOT rice DOT edu Message-Id: <7704-Tue14Aug2001195829+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com In-reply-to: <10108141550.AA12856@clio.rice.edu> (sandmann@clio.rice.edu) Subject: Re: Fw: Fstat.c patch References: <10108141550 DOT AA12856 AT clio DOT rice DOT edu> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > Date: Tue, 14 Aug 2001 10:50:54 -0500 (CDT) > > > We need to find a way to determine the drive letter where a file lives > > given only a handle on which that file is open... Any ideas? > > I've got a prototype for existing files. We modify _open to convert > long name to short name, then do the open by short name. The drive > letter is then correct. But as noted, this doesn't work with device > names at all. Does the LFN open work with devices? That is, if we use LFN open on devices, can we then reliably determine that they are devices? If so, this might be good enough: the st_dev member is fake for devices anyway. For devices, we need to be able to determine other attributes (those which _get_dev_info returns and some others). I think we need to test all the IOCTL functions called by the library and see which open (SFN or LFN) is better. > For new files short of reopening I don't have a fix. We should solve this as well, somehow. > Another thought it to use the 71a6 information which provides a volume > serial number - I'm not sure how we use this yet, but this might be > better. is there a way to find out the drive given the serial number? > Note that on a valid handle 71a6 appears to fail for device handles, > which may be another hint on how to deal with devices on W2K. That's good to know, but I'm afraid I don't see how does it help with any of the problems we are considering. Are you suggesting to use the failure as a sign of a device? If so, we will need to find a way to distinguish between a failure-because-device and a failure-because- invalid-handle.