RAMFS.IFS had a bug that causes problems for Pure 32-bit OS/2 programs.

You've come here because you have asked a question similar to the following:
I am using one of the programs in the Command Line Utilities or the 32-bit Command Interpreter that performs wildcard searches, and it produces strange results when used with a RAM drive provided by the RAMFS.IFS installable filesystem driver.

This is the Frequently Given Answer to that question.


The RAMFS.IFS filesystem driver is known to be buggy. In discussion of this very issue in the Fidonet echo for pre-release testers of my softwares, Lee Aroner pointed out two bugs in it that are already well known: It does not set up Drive Parameter Block structures properly, and it incorrectly returns with the carry flag set from IOCtl calls. The behaviour that you have observed is the symptom of yet another bug in RAMFS.IFS, which was discovered on 2001-08-29 by some of the pre-release testers who happen to use it.

On 2001-09-17, I diagnosed what the problem in the RAMFS.IFS code was and how to correct it, and encouraged its users to contact its author and have xem make the relevant changes. On 2001-10-07, one of the users reported to me that he had contacted the author, who had told him that xe had ceased working on the software.

This problem kept being reported to me, and I kept telling people what the solution was and to contact the RAMFS author. In exasperation, I created this web page in 2002-04 (some six months after I had first started telling RAMFS.IFS users how this problem could be corrected and to tell the author about it) and started pointing everyone that came to me reporting this RAMFS.IFS bug towards it.

A week later, the bug was fixed by Karl Olsen. (He then complained to me that I should have chased him down personally, which I thought a bit rich. RAMFS.IFS is not my software and I am not even a user of it, yet I was the one who went to all of the effort of diagnosing what the problem was, fielded all of the RAMFS.IFS users asking for support for six months, nagged them again and again to tell the author - since they were its users, and knew who the author actually was and how to contact him -, and handed the author the solution on a platter.)

Because of the existence of this web page, therefore, this particular RAMFS.IFS bug is now fixed.

Versions affected

All versions of RAMFS.IFS prior to version 1.01 are affected.


32-bit applications programs see incorrect directory contents for ram disc provided by RAMFS.IFS. The severity of this depends from exactly what use is made of this information.

For example: The operation of commands such as del (from the 32-bit Command Interpreter) and xdel (from the Command-Line Utilities) is severely impaired, which is a severe problem if the deletion of files on ram discs is necessary to the smooth running of the system.

How to replicate the bug

Create a file named dups.txt on a ram disc provided by RAMFS.IFS (designated as drive t: in this example). Run the command

xdir t:dups.txt
and note the output.


This bug causes the operating system to provide incorrect information to 32-bit applications about the content of ram discs. It does not appear to be possible to bypass any operating system security feature using this bug. Given the nature of the bug, it appears to be impossible for a malicious application to reliably exploit this bug in order to affect the operation of another application. (There are far easier direct methods for doing so, in any case.)

What is actually going wrong

RAMFS.IFS, like other OS/2 installable filesystem drivers, communicates with the OS/2 kernel using a 16-bit interface. When a pure 32-bit OS/2 application program calls the 32-bit OS/2 system API to perform a filesystem operation, the OS/2 kernel internally converts the input parameters to 16-bit, calls the appropriate 16-bit installable filesystem driver entrypoint, and upon return converts the output parameters back to 32-bit before returning them from the system call to the 32-bit application.

A bug in RAMFS.IFS that causes it to return garbage in an output parameter is causing the OS/2 kernel to convert arbitrary junk in a directory search output buffer from 16-bit to 32-bit, which is then returned to the 32-bit program. As a consequence, 32-bit OS/2 programs see extra directory entries containing nonsense when they perform directory searches.

The particular bug in RAMFS.IFS that is relevant here is in SRC\FINDFIRS.C. The exact match path does not assign a return value to *pcMatch, the output parameter that the OS/2 kernel uses to determine how many directory entries in the directory search output buffer it needs to convert from 16-bit data structures to 32-bit data structures. The value returned is thus whatever junk the portion of memory holding that parameter happened to contain when the OS/2 kernel called the filesystem driver.

16-bit OS/2 programs tend to be blind to this bug, partly because the OS/2 kernel does not perform the conversion of the results returned from RAMFS.IFS from 16-bit form to 32-bit form and so does not introduce the extra junk directory entries into the output buffer. This is why 16-bit OS/2 programs, such as IBM's 16-bit CMD and version 1.0 of the Command Line Utilities, do not manifest problems with RAM drives driven by RAMFS.IFS.

Local fix

There is nothing that a 32-bit OS/2 program can do about these bugs in RAMFS.IFS. Indeed, there is nothing that applications programs should do. The bugs are in the filesystem driver, not in the applications. The only way of fixing the bugs is to take the source code for RAMFS.IFS fix the errors and recompile the driver.

Throughout the many months before the author finally corrected the bug and issued a service fix, I encouraged users of RAMFS.IFS to coördinate doing this with the author of RAMFS.IFS, so that everyone can benefit from the fix.

Temporary fix

A trial fix for RAMFS.IFS was released to a limited number of RAMFS.IFS users for testing. This has been superceded by the service fix.

Service fix

The service fix for this bug is to upgrade to version 1.01 .

© Copyright 2002-2002 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.