Undeleting a file: how is it done?

[Ruud]

From MS-DOS 5.0 on one can undelete a file but only if nothing else has been changed in the mean time. AFAIK when a file is deleted, the information in the FAT table, both tables to be precise, is deleted as well. This information has to be deleted otherwise how can the OS see that a sector is free to be used again? So how is an undelete possible then?
So I'm clearly missing something. Who knows what?
Thank you in advance!

 

[Gary C]

When its deleted, it just changes the first character of the filename in the FAT to something that indicates its no longer used so you can just change it to a different character and it all comes back as long as the FAT entry or any part of the chain hasn't been overwritten.

Thats why undelete asks you for a character to put in the file name when you run undelete.

(as far as I remember)

 

[whartung]

As Gary C mentioned, the deletion of a file is mechanically trivial, setting the character in the name.

When a file is created, several things happen.

An entry is logged in the directory associating a name with the file.

Sectors of data are written out, and the entry pointed to the first sector of the file. The remaining sectors are linked with each sector having a pointer to the next sector of the file.

Finally, a bitmap of free sectors is maintained by the system. All of those sectors that are used, get their corresponding bits marked as in use.

When a file is deleted, the directory entry is tagged as available so that it can be reused. Similarly, the bitmap is updated so that all of the files sectors are now marked as free and available.

What remains, however, is all of the sector pointers. The directory entry still points to the first sector of the file, and each file sector remains unchanged.

So, file recovery consists of reclaiming the directory entry (with the new character for the file name as Gary mentioned), traversing the in place sector chain, and then updating the sector bitmap to tell the system those sectors are again in use.

This is why it's important nothing else has been done before you try the undelete.

If an existing file is extended, it could claim one of the newly freed sectors and overwrite it, thus breaking the deleted file's chain of sectors.

If a new file is created, it can stomp on the deleted directory entry. Either of these will make complete recovery of the file, if not impossible, much more difficult.

Mind, forensic analysis of a disk can recover all sorts of remnants of things. But those would mostly be incomplete files. But it's also important to understand why deleting a file is not "safe" if you're trying to remove sensitive information.

 

[Agent Orange]

When its deleted, it just changes the first character of the filename in the FAT to something that indicates its no longer used so you can just change it to a different character and it all comes back as long as the FAT entry or any part of the chain hasn't been overwritten.

Thats why undelete asks you for a character to put in the file name when you run undelete.

(as far as I remember)

Possibly Greek lower case "lambda": λ

 

[Chuck(G)]

Possibly Greek lower case "lambda": λ

Hails back to CP/M and the original 3740 SSSD 8" floppies that were factory-formatted with a pattern of hex E5. A brand-new floppy would thus be seen as containing no files.

So the "deleted" flag is 0xe5. However, it's possible to specify 0xe5 as the first character of a file name, so MSDOS changes it to hex 05.

 

[Agent Orange]

Hails back to CP/M and the original 3740 SSSD 8" floppies that were factory-formatted with a pattern of hex E5. A brand-new floppy would thus be seen as containing no files.

So the "deleted" flag is 0xe5. However, it's possible to specify 0xe5 as the first character of a file name, so MSDOS changes it to hex 05.

It's been a while since I fired it up, but PC Tools (DOS) has a utility for undeleting files and I think you can more or less view the process. Of course this assumes that there has been no recent write activity to the file area.

 

[Chuck(G)]

A major difference is that CP/M overwrote the first byte of the directory entry with 0xE5, which is the "user area" byte, to delete it. So the original file name was preserved in the succeeding 11 bytes. DOS didn't have that first byte, so the first character of the file name gets clobbered.

Another major difference is that CP/M keeps allocation information in the directory entry, while DOS keeps it in the FAT. Undeleting a CP/M file is therefore more likely to be successful.

 

[Agent Orange]

A major difference is that CP/M overwrote the first byte of the directory entry with 0xE5, which is the "user area" byte, to delete it. So the original file name was preserved in the succeeding 11 bytes. DOS didn't have that first byte, so the first character of the file name gets clobbered.

Another major difference is that CP/M keeps allocation information in the directory entry, while DOS keeps it in the FAT. Undeleting a CP/M file is therefore more likely to be successful.

The last time I worked with CP/M was on the job back in '87-'88, so I scarcely have any memory of it. I'm thinking that DOS changed the leading character to the lower case lambda and it was a flag to go ahead and write in that area.

P.S. Never much cared for CP/M, but I can see there is a good bit of interest here on the forum for it.

 

[krebizfan]

When the space for a deleted file gets reused is a crucial issue in recovering the deleted file. FAT32 is easy. The first cluster search for a new write starts off at the last cluster allocated so until all the clusters on a disk were written to and the search loops past the beginning, all deleted files are safe from getting written over. I'm not as confident about deleted files being protected with DOS 5 or 6 and I never spent the time needed to understand how CP/M's allocation bitmap worked with deleted files.

 

[Chuck(G)]

With CP/M everything's in the directory entries--the allocation bitmap is constructed from those at disk login time. If the file is longer than can be described by a single directory entry, others are created that use the same file name, but different "extent" numbers. One takeaway from this scheme is that large files with un-allocated space in the middle of the file are possible--so-called "sparse files". Fairly handy if you're building a hashed-entry database.

 

[Ruud]

Finally, a bitmap of free sectors is maintained by the system. All of those sectors that are used, get their corresponding bits marked as in use.

Aha, this was the info that I was missing. Now things make sense. Thank you very much!

 

[krebizfan]

DOS 5 made recovery of a file easier with the Mirror utility delete tracking which keeps a copy of the file's original directory entry and FAT chain in a special file. That is necessary to undelete a fragmented file that has other clusters not in use between the clusters it is using.

Unfragmented files are easy to undelete since the chain of clusters will be determined by the length of the file.

Third parties offered TSR's that would move the file being deleted to a special directory and keep it there until the file is deleted from the special directory. That prevented the file from being overwritten for some time. Undelete consisted of moving the file back to its original directory.