13.000 files in a directory. I don't know if FAT entries supported a number that high (it seems an insane value to me). Why not using one PHYSICAL file to store them (like .dbf)?.

I really don't think you could put more than 1024 or so files in a directory in DOS... Hopefully Qbix or someone will comment.

There is no set limit to the size of a FAT directory. There is a limit only to the amount of files that may be stored in the root of the drive.

as far as I know dosbox doesn't really have a limit. but it stores all files in the current directory
in a STL list I think. and then starts sorting all the entries.
Both will eat memory I think.

There is a limit on the amount of directories though.
But the structure wasn't designed with 13K directories in mind so it's quite possible that something breaks at those sizes.

Hi,

I tried the same on a modern machine (the other was a 500MHz 128MB computer). End of story is: The dir-command just goes on for ages, but at the end finishes allright.
So next question: I guess the low performance is due to the fact, that the cache is filled at the same time. Is there a way to disable the cache - at least for certain directories?

Thank you very much for your replies!

Bye Ralf

uhm yes that is possible, but only by modifying the source of dosbox.

I don't assume that is an option for you.

You are free to find a programmer who makes these modifications for you, that's the joy of open source. It's perfectly legal to do so. DOSBox is not hard to modify - any C++ programmer should be able to work on it.

I took a look at the DOSBox source and ran away screaming. It's easy to compile but hard to understand (unless someone has added a lot of comments recently...).

Actually the slowdown verifies even on mount command.

drive_cache.cpp, line 699, move the sort out of the loop (this fixes DIR command)

1	for (Bitu i=0; i<dirSearch[dirID]->fileList.size(); i++) {
2		CreateEntry(dirFindFirst[dirFindFirstID],dirSearch[dirID]->fileList[i]->orgname);
3		// Sort Lists - filelist has to be alphabetically sorted, even in between (for finding double file names) 
4		std::sort(dirFindFirst[dirFindFirstID]->fileList.begin(), dirFindFirst[dirFindFirstID]->fileList.end(), SortByName);
5	};

drive_cache.cpp, line 636, move the sort out of the loop (this fixes MOUNT command)

1		while ((tmpres = readdir(dirp))!=NULL) {			
2			CreateEntry(dirSearch[id],tmpres->d_name);
3			// Sort Lists - filelist has to be alphabetically sorted, even in between (for finding double file names) 
4			// hmpf.. bit slow probably...
5			std::sort(dirSearch[id]->fileList.begin(), dirSearch[id]->fileList.end(), SortByName);
6		}

This fixes both issues and doesn't seem to break anything.
I couldn't understand why the filelist should be sorted in between. Could anyone please explain?

from the comments it would appear for double filenames
so
file and File (on case sensitive filesystems.), but I'm not certain. Finsterr wrote this part and he is inactive for quite a while.
Although the whole cache will be removed oneday.

To remove the cache temporary.
look at drives.h
there is a drive_cache added to each drive.
you can replace it with a no-drivecache. This is used to check if bugs happened due to drive_cache.
And some lowmemory ports (pocketpc) use it to save some memory.

HunterZ wrote:

I took a look at the DOSBox source and ran away screaming. It's easy to compile but hard to understand (unless someone has added a lot of comments recently...).

😀

But honestly, DOSBox source is good in most parts. Comments are _not_ a good measurement for code quality, as they tend to be the first things that acquire bugs. The general structure is logical, hackiness is bearable, and there's some OO put to good use. It's not an example of perfect application design, but it IS good to understand (unless you are talking about the CPU, which is a science by itself).

There's really no way to fix this before next release?

no.
Oneday I'll remove the drive_cache and add my new drive/dos system.

The sorts you mention can be removed probably for the case insensitive filesystem like windows.
But not in general.