RAMFS.IFS had a bug that causes problems for Pure 32-bit OS/2 programs.
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.
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.
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.txtand 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.)
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.
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.
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.
The service fix for this bug is to upgrade to version 1.01 .