I suggest using DR-DOS 6

There is an 'implied' maximum directory depth limitation with FAT filesystems, resulting from the maximum 256 character total path restriction.

There is also a 'root directory entry' max restriction, but I forget what it is off the top of my head.

If this structure is created on, for example, Windows 11 and then accessed by MSDOS, a guess would be that you are hitting the path size limit of MSDOS.

Hundreds of directories in DOS/Win 3.x is a bad idea. Even if it's supported by the OS, you will encounter old programs that become confused.

I work around this by creating A B C ... X Y Z directories and putting the games/programs in the appropriate subdirectory

e.g.

C:\DOSAPPS\O\OUTRUN
C:\WINAPPS\N\NETSCAPE

Some programs don't like this and have to be installed in root, but most work well like this.

Thanks all so far.

For clarification:

It’s not about lengths of pathes / directories.

It’s like this:
- Games
— subdir1
— subdir150

They are all visible and accessible initially. But after having ~5 directories visited, all directories become empty / not accessible.

It is not related to which directories I visit first. After having eg five opened (after another) the described situation occurs.

Ah I saw the last post too late. I already structured it like that 😀 but thanks

But yea maybe it’s simply a msdos limit

Are you using bare command.com for "browsing" (like cd and dir commands) or some file manager? Could it be a file manager problem and not DOS per se?

Great point.

I normally use NC.
But even when then quitting and accessing via pure commandline the issue remains: empty folders.

Marco wrote on 2025-10-10, 12:09:

They are all visible and accessible initially. But after having ~5 directories visited, all directories become empty / not accessible.

It is not related to which directories I visit first. After having eg five opened (after another) the described situation occurs.

This is strange. It's as if a buffer is running out or something.
Is it related to SmartDrive, maybe?

Also, you can try running FastOpen, maybe it helps.
It basically keeps a copy of index in memory for quicker file access.
Not sure if it will work with network drives, though.

Great. I will check both options as I mainly use smartdrv. Thank you

Great. I will check both options as I mainly use smartdrv. Thank you.

Just checked: fastopen can’t be used for network drives. So maybe I try with smartdrv off next.

IIRC fastopen only works on executables, and FILES= does nothing for listing directories. You want to play with BUFFERS= but frankly that just should not happen. Too low buffers would just slow the listing (require re-read of the media), not cause the problem you have.

I would blame SMARTDRV (or whatever disk cache you're using), MSCDEX bugs (even if the problem also appears on HDDs, because it sorts of integrates itself into OS and could cause such issues), or even bad RAM. You could try MSCDEX from Win3.1(1) to see if it helps any. If you're using EMM386 disable that, see if it helps, could be a weird UMB issue that just happens to be triggered by the usage pattern you have.

I have burned many DOS and early Windows collections of DVD-DL 8GB. Standard ISO. Readable with MSCDEX. Try not to use over 3 levels of directories because few games and software have their own levels of directories. UltraISO version 9.x is the best software for my experience to make and burn legacy ISOs, you can set special limitations for DOS. Works in XP to 11.

Do I understand you correctly that the issue happens both with CDROMs that have this structure as well as with network drives with that structure? What network software do you use to access the network drive?

As both standard DOS 5 network drivers (Novell's VLM, Microsoft SMB stack, ethdosfs) and MSCDEX use the same "installable file system" infrastructure, this could in fact be an issue in the MS-DOS kernel with any kind of installable file system.

If you want to stay safe never exceed 512 files/directories entries per directory, and never go beyond 9 levels deep creating subdirectories.
Some implementations may be more tolerable, others will cry foul at first sight.
Also keep an eye on conventional memory availability: some programs allocate it thinking it is "just a few files", and end up swallowing it like there is no tomorrow if a scenario is non-standard.

I won’t bet anything right now that it is also valid with cdrom but for sure with smb shares using msclient.
Thanks again I see it could be smartdrv, usage of Norton commander or simply a kernel issue (by design). Fastopen and buffers / files can be excluded. Too low conventional memory and too „deep“ file structure as well.

Thanks