Re: path name limits

On 2002-10-23, Bart Oldeman wrote:

>> What are tha path name limits imposed on freedos? MS-DOS has 66
>> and DR-DOS has 63, I need a few more :(.
>
> Any _DOS_ (should) limits _path_ to 67 characters and name to 8.3
> characters. This gives 67+\+8+.+3=80 characters for full path.
>
>> Also I there any nested subdirectories limits?
>
> No, only on path length. This mean, that you can't have more than
> (67-C:)/2=65/2=32 levels (where 2 is one for backslash and one for
> directory name itself). This limit causes troubles when you try to
> access more lengthy path, created on network or under Win9x
> (especially when some apps like Photoshop makes very deep nesting
> with long names in C:\PROGRA~1). 

I just noticed a slight difference between DR-DOS 7.03 and plain
MS-DOS 7.10. Under DR-DOS, when you're inside the following directory

C:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\> MD 3

still works fine, but a subsequent

C:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\> CD 3

does not. Under plain MS-DOS, the "MD 3" gets rejected already.

Of course, it still works in a DOS box under Windows 9x and you
can create even deeper directory structures there, which, however,
are not accessible by any plain DOS due to the fixed length of
the entries in the Current Directory Structure (CDS).

There is one exception, though:

DR DOS 3.31 - 6.0 should have no problems to traverse through
directory structures of any depth, at least when using
relative paths.

The reason for this is that these old DR DOS issues were still
utilizing a heavily modified CCP/M-86 kernel (derived from
DR Concurrent PC DOS 86 6.0) with the CP/M API code removed
and a DOS API emulation layer added, instead. Their CDS was
only an emulated one, which got synchronized with the internal
state at certain times.
The kernel itself kept track of directories on the basis of
a dynamically linked list of clusters, ASSIGN, JOIN, SUBST
and friends were all based on this system as well, so that
there was no inherent limit in the depth of directories except
for the fake stuff the kernel had to put into the emulated CDS.
AFAIR, if the path was too long, it was truncated at the
beginning. This mechanism would have allowed some kind of
symbolic links, I remember I did some experimenting with
this when I researched the pre-CDS and CDS structures
in DR DOS 3.41, 5.0, and 6.0 back in the early Nineties,
but as far as I know, it was never actually used for
such purposes.
Since many dirty DOS applications directly peeked or poked
around in the CDS and, depending on what they did, they
would not work under these DR DOS issues, their engineering
had to completely redesign the kernel to use native DOS data
structures including a genuine CDS array.
Hence, with the introduction of the BDOS 7.0 kernel (NetWare
PalmDOS 1.0 in 1992), this and all later issues of the DR-DOS
family (DR DOS "Panther" & "StarTrek", DR DOS 6.0 "business
update 1993", Novell DOS 7, OpenDOS 7.01, and DR-DOS 7.02 - 7.05)
now had the same limits as known from MS-DOS/PC DOS. That's the
price of compatibility.
Ironically, with the introduction of Windows 95, Microsoft managed
to remove just this very limit in their product (at least under
the GUI), while at the same time they incorporated several features
of the new DR-DOS CDS handling into the underlaying MS-DOS - for
example the organization of the pre-CDS during CONFIG.SYS under
MS-DOS 7.0+ works significantly different than in previous issues
of MS-DOS and almost identical to how it works in Novell DOS 7+,
and they also copied LASTDRIVE=32 and the CDS loadhigh feature... ;-)

Since old issues of DR DOS supported longer paths and Windows 9x
does as well now, users might sometimes need to access files in
such too-deep directories under plain DOS (I have been in this
situation several times already). Hence it might be a good idea
to extend DOS (at least FreeDOS and DR-DOS) to cope with it, as
long as this does not compromise general compatibility and does
not cost much memory.

I see one possible way how to possibly extend the path length
under plain DOS in a relatively compatible way by allowing some
kind of SUBST to work with relative paths. This is no 100%
solution, I know, but in contrast to other solutions, it would
not immediately break all applications which depend on a DOS
compatible CDS layout. This idea:

Since most applications have fixed internal paths lengths,
we would need a slightly modified SUBST and kernel to work
with chained paths split over several CDS entries (at least
with LASTDRIVE=32 we should have some free ones, otherwise
we could even extend this a little further), so the user
could assign a special SUBST drive like:

Syntax:

SUBST /X[:d] d: d:\path

Example:

SUBST /X Z: C:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2

and then work with the Z: drive letter to traverse into the directory
structure even beyond the old length limit. Since the CDS entry for Z:
could not hold the true path, the remainder of the actual path need to
be stored in another drive slot. Let's assume, drive Y: would not be
used at the moment. Then we could assign

Y: = C:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2
Z: = Y:\A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z

The entry for Y: should have a special attribute set which would mark
the entry as being "read-only" (or even "hidden" except for private
use by the kernel or SUBST) for as long as there are other references
to it (Z: here). SUBST Z: /D should remove both entries if there are
no further references to Y:.

The SUBST /X[:d] parameter might allow to specify the slot d: to be
used for this purpose (if it is still unused). As long as there are
free slots in the CDS, the kernel could implicitly assign drives
on a temporary basis, as soon as a user traverses into deeper
directory structures, but this would create some new implications.
Disadvantage: The latter idea might cost some additional memory.

(However, if the kernel would have such a feature added, we could
also easily add so called "floating drives" - under DR DOS 3.31 - 6.0,
Concurrent DOS and Multiuser DOS, the INT 21h/AH=3Bh DS:DX ASCIZ
string can be in this extended format:

[d:=]d:\pathspec

where the first drive letter d: specifies a SUBST drive letter,
so you can - without much hassle - specify floating drives on
the fly and directly from inside of any applications. This is,
why SUBST was an internal command in old issues of DR DOS
COMMAND.COM. Multiuser DOS still makes use of this for the
"load drive" feature: Unless used for a different purpose,
drive L: is automatically and dynamically assigned to the
load drive of the currently running application, so the
application can always refer to L: to find itself and
associated files. Sometimes quite convenient to have.)
 
What we would need to research is if adding a new CDS attribute
would cause trouble with some applications (some other attributes
are already in use by other DOS clones like PTS-DOS). (I would
also like to introduce a few other drive-by-drive attributes,
like a "force verify" flag (for forced verify on floppies even with
VERIFY=OFF), an "ignore verify" flag (for harddisks even with
VERIFY=ON), a "read only" flag, a "LFNs allowed" flag and a few
more, but this might also be located at a deeper level, one flag
byte per drive.) I'm just kind of brainstorming here...

When speaking about paths limits, there's one more thing to
think of for optimal compatibility with the DR DOS family of
operating systems. This does not affect the kernel (at least
not now) but all library or application level code dealing
with paths: Under any issue of DR DOS, a file or directory
name is physically bound to the 8.3 format in the filesystem.
This is just the same as under MS-DOS/PC DOS. But under DR DOS
any file or directory can have a password, access rights, and
ownership associations assigned to it. The password and the
corresponding access rights are stored encrypted in some
of the ten reserved entries in the directory entries in the
filesystem (maybe we could add this to the FreeDOS kernel
as well at some later stage, at least optionally), but for
the moment, it is irrelevant, where this extra information
is actually stored in the filesystem on disk (in a different
implementation it could also be stored in some external container
file or even in a remote filesystem somewhere else). What's
important here is how it is /specified/ in a filespec.
A password can be up to eight characters long and is attached to
the usual 8.3 file or directory name and separated with a semicolon
(since DR-DOS 7.02+ optionally with two semicoli). Syntax:

filename[.[ext]][;[;]password]

So, a valid filespec under DR DOS could look like this:

d:\dir1.ext;dir1pwd\dir2.ext;dir2pwd\dir3.ext;dir3pwd\file.ext;filepwd

This should be taken into account in any path crunching routines
(most commercial libraries do not, unfortunately, although it would
be very easy to fully support this extension without any backdraws
for MS-DOS/PC DOS - In case someone wants to use it, my CUILIB library
contains a variant of the Pascal FSplit procedure which takes DR-DOS
into account, FSplitDR it almost a drop-in replacement for the old
FSplit). Also, passwords should be taken into account when calculating
the maximum length of a valid filespec at user level, under DR-DOS
it can be 10 bytes longer than under MS-DOS/PC DOS.

>> I believe MS-DOS has a limit of 11.
>
> Wrong beliving.

Yes, there is no such limit except for that imposed by the length itself.

However, some redirector driver implementations may impose restrictions,
for example MSCDEX/NWCDEX do not support more than eight sub-directory
levels simply because this is the limit defined in the ISO 9660
CD filesystem.

Greetings,

 Matthias

-- 
<mailto:[email protected]>; <mailto:[email protected]>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org

"Programs are poems for computers."