Windows 95 Permanent File Deletion Process

When users bypassed the Recycle Bin in Windows 95 using modifier keys like Shift+Delete, the operating system skipped its staging database and initiated a permanent low-level deletion directly through the file system. Instead of moving the target file to the hidden \RECYCLED directory and generating a tracking entry in the INFO file, Windows 95 invoked direct Win32 file-system APIs. This process decoupled the file's clusters in the File Allocation Table (FAT) and flagged its directory entry as deleted, leaving the raw data intact on the physical disk until overwritten.

Shell-Level Detection and Flag Stripping

In Windows 95, standard file management operations within Windows Explorer are governed by the shell API function SHFileOperation. Under standard circumstances, a deletion command passes the FOF_ALLOWUNDO flag, instructing the shell to preserve the file by moving it to the designated drive's RECYCLED folder.

When a user holds the Shift key while issuing a delete command (via keyboard shortcut or context menu), the shell queries the keyboard state using GetKeyState(VK_SHIFT). Detecting the modifier, the shell:

  1. Prompts the user with a permanent deletion confirmation dialog instead of the standard "Send to Recycle Bin" prompt.
  2. Omits the FOF_ALLOWUNDO flag from the SHFILEOPSTRUCT structure.
  3. Bypasses the Recycle Bin namespace extension entirely, preventing the generation of temporary catalog names (e.g., Dc1.txt) and associated metadata logs in the hidden INFO record file.

API Invocation and the IFS Manager

With the undo flag excluded, the Windows 95 shell bypasses high-level user space management and calls the standard Win32 file manipulation functions: DeleteFile() for files or RemoveDirectory() for folders.

The Win32 subsystem forwards this request to the Windows 95 Installable File System (IFS) Manager (IFSMGR.386). The IFS Manager serves as the 32-bit protected-mode arbitrator for file operations, passing the deletion call directly down to the resident file system driver—typically VFAT.386 (supporting FAT12 and FAT16 in early releases, and FAT32 starting with Windows 95 OSR2).

Low-Level FAT Modifications

Once VFAT.386 receives the command to delete the file, it executes the traditional DOS-era file deletion routine directly on the disk structures:

  1. Directory Entry Modification: The driver locates the 32-byte directory entry matching the file path. It overwrites the very first byte of the file name with the hexadecimal value 0xE5 (the Greek lowercase sigma σ in ASCII). This single-byte change marks the directory record as unused and free for future file creation, while leaving the rest of the metadata (creation date, attributes, and starting cluster pointer) preserved. For long file names (LFNs), the associated preceding dummy entries are also flagged as freed.
  2. FAT Cluster Chain Deallocation: The driver reads the starting cluster offset from the directory entry and navigates the File Allocation Table. It traverses the linked list of clusters assigned to that file, resetting each mapped entry to 0x0000 (or 0x00000000 in FAT32). This effectively marks the clusters as unallocated free space in the drive's allocation bitmap.

Sector Data Preservation

At no point during the bypass deletion process did Windows 95 perform a secure wipe or overwrite the physical sectors where the file contents resided. Because the operation merely severed the FAT chain and marked the directory header with 0xE5, the original file payload remained intact on the disk platter. The data would only be destroyed once new write requests were assigned to those deallocated clusters, which allowed third-party utilities and traditional MS-DOS recovery tools to reconstruct bypassed files if executed before disk overwrite.