Setting TEMP and TMP to Different Drives in MS-DOS 6.22

Setting the TEMP and TMP environment variables to different drives in MS-DOS 6.22 causes software to split temporary file storage across both locations depending on which variable each specific application evaluates. This article examines how MS-DOS and DOS-era software prioritize these variables, the performance and storage implications of using multiple drives, and the potential errors that arise when splitting paths across separate physical disks or RAM drives.

Variable Independence and Application Behavior

MS-DOS 6.22 does not link or synchronize the TEMP and TMP environment variables. They operate independently, and the operating system itself does not validate whether they match.

Standard MS-DOS commands, such as piping (|) and redirection, along with native utilities like DOSSHELL, typically look for the TEMP variable to create scratch files. Conversely, many development tools, such as Borland Turbo C or Microsoft C/C++, as well as third-party utilities and Windows 3.1 applications, prioritize TMP or check TMP before falling back to TEMP. When these variables reference different drives (such as TEMP=C:\DOS and TMP=D:\TEMP), temporary files are written to whichever drive the running program specifically queries.

Performance Disparities with RAM Drives

In MS-DOS 6.22, users commonly configured a RAM drive using RAMDRIVE.SYS to accelerate temporary file operations. If TEMP is assigned to a RAM disk (e.g., D:\) while TMP remains on a conventional hard drive (e.g., C:\TEMP), only applications coded to check TEMP will benefit from high-speed memory reads and writes. Software referencing TMP will continue to read and write to the mechanical disk, creating inconsistent system performance across different tasks.

Storage Capacity and Failure Risks

Assigning TEMP and TMP to separate drives creates isolated storage bottlenecks:

• Asymmetrical Disk Space: A program writing large temporary files might exhaust the space on one drive while the other drive remains largely empty. When a temporary drive fills up, the program will fail with "Disk full" errors, regardless of available capacity on the alternate drive.
• Missing or Unmounted Drives: If one of the variables points to a drive letter that is not loaded, has been unmounted, or represents a removable drive that is not present, applications querying that variable will fail or trigger the MS-DOS critical error handler prompt (Abort, Retry, Fail?).

Cross-Drive File Operations

When an application finishes writing a temporary file, it frequently transfers that data to a permanent location. If the temporary directory and the final destination directory are on the same drive, the file system can often perform a fast directory-entry rename. If TEMP or TMP resides on a different drive than the target working directory, MS-DOS is forced to perform a complete cluster-by-cluster copy across the drives followed by a file deletion, increasing execution time and disk wear.