From: "Tim Van Holder" To: Subject: RE: Draft patch for opendir() extension Date: Wed, 27 Dec 2000 09:58:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id DAA26552 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 > > > The above just passes the name of the file, not the directory where it > > > ``lives''. > > Hmm. I thought that an fsext_open hook got the name as passed to open(). > It does. > Did you plan to have fsext_open hook be the place where these fake > entries are registered? Yes, for those fsext functions where this makes sense. /dev entries can usually register the names they support at startup. I guess I'd need two sets of register/deregister: one taking a single char* (register_fake_entry ("/dev/zero") for situations where the fake entry is known in advance, and one taking a fd and a char* (register_fake_entry (7, "e:/my/fake/entries/test1") for when they're created on the fly (as with sockets, I expect). The latter function would have its argument fixpath()d. > > If not, how would the /dev/zero support know it's being asked for > > /dev/zero and not d:/my/favorite/numbers/zero? > The case of "d:/my/favorite/numbers/zero" is easy, but what about > "d:/dev/zero"? My point was that you said it got the name, not the location, so in both thos cases you'd get 'zero'. As for 'd:/dev/zero', fake entries registered with the first function would not be fixpath()d and would have to be recognized regardless of drivespec. I'll certainly agree that this is non-trivial (but nothing dealing with filenames is trivial) > Why isn't fsext_entries[num_read - need_fake_dot_dotdot] good enough? > Since num_read never gets past the NULL entry in fsext_entries[], you > don't need the above loop and other complications. num_read is further incremented by reading 'real' entries, so it would exceed the bounds of the array. Remember, I'm currently returning entries in the order fake dots - fake entries - real entries. Returning them last would help in this respect, but would probably cause problems in determining whether we've reached the end of the real entries (you'd probably need to call findnext() each time to check).