During MS-DOS days, an Undelete command existed and provided three levels of protection. Sentry is pretty much the same as the Recycle Bin, it moves deleted files to a directory called Sentry. Tracker used a hidden file named PCTRACKR.DEL to record the location of deleted files and regular undelete. The first two level of protection required disk space which is understandable and also an amount of RAM (13.5 Kb). Why is that since I believe, and I am not entirely sure, that the Recycle Bin does not require any memory.

  • 1
    Why should any of them use RAM except when actively trapping the DELETE command?
    – RonJohn
    Feb 11, 2023 at 5:54
  • 1
    The first characters of the names of the deleted files, which are replaced with the "deleted file" marker in the directories, must be stored somewhere.
    – Leo B.
    Feb 11, 2023 at 7:44
  • Wouldn't that be gone when turning off or restarting the PC? Feb 11, 2023 at 8:09
  • PCTRACKER.DEL is not an 8.3 file name. Feb 11, 2023 at 8:17
  • 3
    @user3840170 the file is called PCTRACKR.DEL. Amusingly, the on-line help in DOS makes the same mistake in at least one place. Feb 11, 2023 at 8:20

1 Answer 1


“Regular” UNDELETE relies only on the standard MS-DOS deletion behaviour: when a file is deleted, the first character of its file name is replaced with a deletion marker, and its clusters are freed. UNDELETE does all its magic when undeleting, with no prior preparation.

“Sentry” and “Tracker” modes modify this deletion behaviour; to do this, a terminate-and-stay-resident program is installed, and calls to DOS’ deletion functions are intercepted and handled by this program. That’s where the additional memory requirement comes from: it’s extra code (and associated data) effectively added to the operating system to enable these features. Under DOS, this was significant — every kilobyte of memory in the first megabyte was precious! So choosing between better protection and more memory wasn’t necessarily straightforward.

When resident, UNDELETE (a subset of Central Point Software’s PC Tools’ DATAMON) occupies 13.5KiB of memory in sentry mode, 9.5KiB in tracking mode. That may seem like a lot, but the resident portion has to take care of quite a few different features, including:

  • intercepting deletion, of course, to provide whichever protection has been requested
  • providing an installation check (on interrupt 0x16 and interrupt 0x2F), and other run-time services (e.g. to query the current status)
  • intercepting DOS calls dealing with free disk space (so that “deleted” files don’t appear to occupy disk space)
  • intercepting DOS calls dealing with errors (to act on “out of disk space” errors by deleting protected files)
  • protecting the SENTRY directories (in sentry mode)

Looking at the resident portion, it seems it would have been possible to make it smaller, but it’s not as simple as one might imagine at first glance.

Under Windows, supporting the Recycle Bin also uses memory, but the impact is far less significant in practice, so enabling it by default isn’t a concern.

  • 1
    Yes, certainly the TSR is going to occupy some memory. But 13 KB seems like a lot, considering the simplicity of what it does. Unless there were more features not yet mentioned, you'd think they could have gotten it much smaller. After all, MS-DOS 1.0 fit the entire operating system and the application program into 16 KB! Even by the time that 640KB was typical, 13 KB was still a noticeable chunk and could make or break your ability to run the latest Microprose flight simulator... Feb 11, 2023 at 19:15
  • 1
    @Nate I’ve expanded my answer to address that side of things a little. (Re. running DOS in 16K, that wasn’t a supported IBM configuration and DOS doesn’t boot with only 16K of RAM, even though booting with 32K leaves ~20K free.) Feb 12, 2023 at 20:52
  • I don't know if my comment is worth another question (and also where) but why was this command not present in Windows? Feb 13, 2023 at 9:23
  • @AnArrayOfFunctions it was available in Windows 3.x running on top of MS-DOS 6 (if the latter’s setup was run or re-run after Windows was installed). Windows 95 and NT restricted hardware access, so DOS UNDELETE couldn’t work there (see this KB article); 95 had the Recycle Bin instead, and NT added that in version 4.0. That doesn’t explain why an equivalent utility wasn’t provided for the NT command prompt; I don’t know the answer to that. Feb 13, 2023 at 13:13
  • @StephenKitt - I would guess that 'overwriting a byte in a name' is not sufficient to get rid of a file in anything except FAT. The directory structure is a tree, not a linear array; the allocated clusters are listed via the MFT record, not chained from the directory. But a similar question might be "why implement delete protection in usermode code rather than in the file system?" (see TOPS-20 for an example of the latter)
    – dave
    Feb 13, 2023 at 15:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .