ls on folder with 11000+ files -> bad address

QNX USERS QNX6 - OS
1

On a QNX6.3.2 box having a harddisk folder with 11000+ files, ls returns with a ‘bad address’ message. The box has a Pentium M 1.6GHz processor and 256MB of RAM.

Utility is executed using

ls folder/*.pgm > ls.txt

The ls.txt file is zero bytes in length when the utility returns.

Using the find utility to accomplish the same is ok

find folder -iname “*.pgm” > find.txt

I’ve seen this ‘bad address’ issue with the rm utility as well, when trying to remove thousands of files.

Has anyone a clue as to why this ‘bad address’ issue occurs?

Will it be fixed in 6.4?

Thanks,
Jacob Dall

2

“Will it be fixed in 6.4?”

Has it been reported to QSSL? Has it been confirmed to be a bug, rather than disk corruption?
11000+ files does not seem very practical. The usual way of dealing with an application with this type of requirement is to create an application tree, eg.

AAAAAA.txt → A/AAAAAA.txt
BBBBBB.txt → B/BBBBBB.txt

You can do multiple levels of this if necessary.

3

If memory serves me correctly (the old QUIC’s forum) I remember an old issue with the filesystem when there were thousands of files in one directory.

What I can’t remember is if this was under QNX 4.X or 6.X or if it’s under both.

But it’s definitely been reported before. I also can’t remember if there were options to turn on to the drivers to extend support for such a case.

Tim

4

It’s unlikely that it is a driver issue. Drivers don’t know anything about the file structure. I vaguely recall a 4.X problem as you describe. I know that a lot of effort was put into making very large directories work with the QNX 4.X file system. I think this was because some standard newsgroup software functioned this way. Could that problem have lived on to QNX 6, sure. On the other hand, I think its entirely possible that with 11000+ files, this user is on to something new. Given the impracticality of having a directory that large, I wonder if it’s even QSSL would even find it worth fixing. That’s why I mentioned the work around.

5

I think Robert Kertn came up with its own file system manager especially to boost performance of newsgroup software.