Mail Archives: djgpp-workers/2000/12/27/03:54:51
> > > 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).
- Raw text -