Mail Archives: djgpp-workers/1998/03/16/12:36:19
> > Yes for djtar, but I'd like better errno's from mkdir, so it's more like
> > Unix.
>
> A better errno from `mkdir' library function? If you can do that without
> bloating the source too much, go ahead and submit a patch. But I should
> warn you up front that DOS makes it very hard to provide good diagnostics
> without doing a lot of expensive tests. DOS error codes just don't map
> too well into the Posix errno values.
Yes, the library function mkdir. My mkdir.c patch was for that.
> > > I think the limitation is not 24 slashes, it's the length of the path
> > > name. Anything longer than 64 characters should make DOS barf.
Sorry, I meant
"C:/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25".
This is 58 (or 59 including '\0' at the end) characters long.
Anyway it doesn't matter, as it's not the solution.
> > Uggh! So is it possible to get more information from DOS, why the operation
> > failed and set errno from that?
>
> It's possible, but it's hard. The best way would be probably to bypass
> `mkdir', call `__dpmi_int' directly and examine the DOS error code.
This is what (the library function) mkdir does.
> > ?
>
> What's the question?
>
> What I meant was that you might get names like "\\server\volume\dir\foo"
> from `_truename', which will utterly confuse some DOS calls and even your
> slash count (DOS doesn't count the first 3 slashes in such names).
That was the question, thanks.
Right now I think that my mkdir.c patch minus the slashes messing is
good. How about putting it into libc?
I'll look into the error codes from DOS, to see if there's a solution
for the too deep directory nesting.
Thanks,
MartinS
- Raw text -