Mail Archives: djgpp-workers/2001/09/23/14:12:12
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Sun, 23 Sep 2001 11:06:14 -0500 (CDT)
>
> > Eli said this:
> > "It's all expected: legacy DOS calls are limited to 64 characters in
> > the directory part of a file name, and to 8 levels of subdirectories
> > (which you exceeded).
>
> If this is the case the code should have an assert in it and bail if
> there are more than 64 chars.
The problem is: where do you put these asserts? The best place is
_put_path, but the test needs to look at _USE_LFN, and you cannot
issue system calls from _put_path, for obvious reasons.
That leaves us with lots of possible places, and a potential for lots
of slow-down.
FWIW, on plain DOS, the too-long names never cause the root to be
substituted for the actual file name: they simply fail, but never do
any harm of the kind that was reported here.
Also, until we understand the problem reported by Wojciech, I don't
think we should cry wolf. Who knows, perhaps the real problem has
nothing to do with 8-level directory limit.
> > Now to the problem: I've tried to keep up with the Win2k discussions. From
> > what I remember some file handling is done with SFNs, because Win2k's LFN
> > handling is a bit broken. So perhaps the changes expose the same problems
> > I experienced when running the Fileutils tests with LFN=n on Windows '98
> > SE?
>
> We are only doing this for open() related handles.
Right; and so I don't think the problem reported by Wojciech is
relevant to these, since it has to do with the length of file names,
not with file handles. Removing files is never about file handles.
- Raw text -