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 Answer
“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
SENTRYdirectories (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.
answered Feb 11 at 8:13
-
1Yes, 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 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 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 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
UNDELETEcouldn’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 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) Feb 13 at 15:28
PCTRACKER.DELis not an 8.3 file name.PCTRACKR.DEL. Amusingly, the on-line help in DOS makes the same mistake in at least one place.