Mail Archives: djgpp-workers/2001/12/27/11:11:52
On Thu, 27 Dec 2001, Tim Van Holder wrote:
> > That won't help, I think: our chdir doesn't test that bit
> > (and does not call stat).
>
> Should be easy enough to add an access(X_OK) to chdir, and modify
> access() and stat() not to set that attribute for UNCs.
More slow-down...
> > The equivalent of "test -d" (IIRC, access(D_OK)) also doesn't check
> > that. These and other cases look at the directory attribute bit,
> > not at the execute bit.
>
> That test is irrelevant; it's the execute bit, not the directory bit
> that matters.
That's what I meant, but backwards: our library functions test the
directory bit, so you cannot change their behavior by simulating the
execute bit.
> > Application code will still not expect such calamities.
>
> Then that application code is broken; we generally deal with Unix
> ports, and such permission settings are fairly common on Unices.
I don't think I ever saw a program which looks at the execute bit of a
directory before it chdir's there. They all test the directory bit, and
sometimes the write bit.
> The trick there would be to know when to release the mapping.
> For cmd.exe that's easy: as soon as you 'popd' away from the UNC.
> For us, that won't be easy to determine. Keeping it mapped until
> program end is undesirable too, especially since there are only
> 25 mappings available at best.
That's the tricky decision, yes. We could try the LRU approach, once all
the available letters are taken, for example. A program which uses that
many different UNC directories at once should be a very rare case, I think.
- Raw text -