Computing desk
< October 18	<< Sep \| October \| Nov >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 19

Unformat: Why doesn't Windows let undo the "format" (or "quick format") command, although it was possible in MS-DOS?

HOTmag (talk) 19:28, 19 October 2024 (UTC)[reply]

In DOS 6, if you were using a FAT formatted drive, the FORMAT /Q command would not actually format the disk. It would copy the file allocation table to an unused area of the disk and replace it with an empty file allocation table. As long as you don't use the drive at all, you can unformat the disk to copy the file allocation table back. When Windows 95 was released, the unformat command was dropped. At that time, and now, there are many data recovery tools available and the Windows mindset is to only go into areas where it can be "the" market. If there is too much competition, Microsoft puts effort into other things. 68.187.174.155 (talk) 19:55, 19 October 2024 (UTC)[reply]

As long as you don't use the drive at all, you can unformat the disk to copy the file allocation table back. Do you have any practical suggestion of undoing a "quick format" in Windows? HOTmag (talk) 20:54, 19 October 2024 (UTC)[reply]

(programmer here with some OS/FS knowledge) MS-DOS used FAT, a very rudimentary file system (as did microcomputer OSes generally at the time, when processing power and disk space were so limited). In that simple FS, there's just that allocation table, and...not much else. Simply copying an area of the disk to another is easy—I mean, that's a basic function a filesystem does whenever you copy a file. (PS this makes it easy for the FS to get trashed, potentially losing all your data, as happened to many people) Modern Windows uses NTFS, a more "modern", advanced, and thus complex FS (which also is much better at not losing your data and doing various advanced things like shadow copy, online backups, RAID distributed volume clusters etc etc).

There is no "file allocation table" in NTFS. Instead there's a "Master File Table" which is a relational database storing the fundamental info about the FS. But simply copying this is not enough to "restore" the FS if anything has been done to it in the meanwhile (The computer has no way of knowing whether or not this is the case. Note this was true of MS-DOS as well, it just played fast-and-loose with your data and decided if it thought it was fine "well, looks okay, you might wanna run chkdsk to be sure though")

The MFT does not store the location of all the data making up files in the FS. It only stores enough info to look up the "head nodes" of the B-tree graph data structure, which is how the data in the FS is organized. Looking up a file's data involves walking the graph structure to look up the clusters containing the file data. (These could even be on multiple different physical storage devices like in clustered volumes, frequently used in "enterprise computing". Remember when your bank lost all your money and account info because their hard drives crashed and they lost their data and their computer systems were offline for days? No?) Yeah this kind of stuff is the sort of stuff theoretical computer science is about—applied math such as graph theory is one big aspect of it.

All "modern FSes" (ext4, XFS, ZFS, btrfs, APFS etc) use various techniques and structures along these broad lines. Much faster, flexible and extensible, conserves space reliable all that jazz. But the tradeoff is more complexity. The MFT doesn't "know" itself where all the data is located for all the files (unlike the FAT in, well, FAT). It just has a "map" for how to get started looking up that stuff. But now imagine a bunch of that stuff is moved without the MFT being updated about it. Now you have to basically go through the entire FS checking that it's in a "consistent" state and repairing it if it isn't. And the computer has no idea whether or not this happened...so it has to do that regardless to be sure. And that's why things are a little more complicated than "just copy this one thing back and forth". Similarly, bringing an Airbus A380 back to "ready-to-fly" status after having it parked in a hangar for a while, is a little more involved than for a Cessna.

PS if you care at all about your data (if you would be upset if I deleted it right now then that means you care about it) back it up, frequently, to multiple places. Set up automatic backups, but periodically make manual ones too. Storage is so cheap these days there's no good excuse not to. If you have only one copy of something you reallt have zero copies of that something. You can't go back in time after you lose something and then make sure you saved it. (This doesn't have to be from hardware/software failure necessarily. "Are you SURE you want to overwrite this file?") --Slowking Man (talk) 03:49, 20 October 2024 (UTC)[reply]

Thank you for this thorough answer. A bit disappointing one, though, because I haven't backed up my disk... But of course you deserve a barnstar for your professional reply.

To sum up, practically speaking, do you think you can suggest any advice to a user who wishes to undo a recent "quick format" she has carried out (in Windows OS), if nothing has been done to the disk for the time being? HOTmag (talk) 09:10, 20 October 2024 (UTC)[reply]

Somehow this helped me understand why a partition on my disk was still accessible (sort of) the same after something started wiping it (it could be viewed and accessed from another partition after some attempts to restore the MFT) AND why trying to fix the MFT didn't fix the partition in question (it never booted again), even though we never figured out what was exactly wrong. Weird closure 10 to 12 years later. - Purplewowies (talk) 02:40, 22 October 2024 (UTC)[reply]

Sure, this is a frequent one. (To save yourself time, just ask that to begin with, instead of for info about how you think you might go about doing a thing. Maybe that way will turn out to not be the best way to go about accomplishing the thing.)

Necessary pre-note: if these steps seem too complex and you're unconfident in your ability to follow them, and the data is anything you don't want to lose, the best course of action really is to find a professional and pay them to apply their expertise to your problem, sorry. If you needed to replace an electrical outlet or do an oil change on a vehicle, and didn't think you were capable of doing so correctly per instructions, you'd hire a professional to do it for you, right?

Expanding on Data recovery § Four phases of data recovery here. Ideal first steps:

If the drive is still plugged into anything, unplug the cables to the drive temporarily. If that can't be done kill the power to the entire thing the drive is in (with a "hard" shut down eg by holding down the power button or yanking the power cord from the wall, not something like hitting "Shut down" in Windows). Yes, trust me on this one. If the drive is still "seen" by a running computer system, that system might be doing things in the background to it you aren't even aware of, overwriting some of your precious data! Then the parts which got overwritten really are lost forever, sorry.
"Clone" the drive (or partition/volume) onto another physical device with disk cloning software. Making a copy. Clonezilla is nifty and simple and can be "livebooted" directly, but you'll need something like a USB flash drive and a running computer to copy Clonezilla to that USB drive. Diskgenius is powerful if you want something in a Windows environment though it's not the most user-friendly (geared towards "computer people"). Ideally do this multiple times to different devices! Further operations are done on this copy, so that the intact original master copy is still there safely untouched, to be gone back to if necessary.

The above steps really are the best things to do and not doing them is taking more risks with that data. (If you don't care about the data, why even bother trying to recover it to begin with? Other than for "fun"/self-educational experience perhaps.) You accept the risks if not following them, caveat emptor and all.

Fire up some data recovery software and point it at that copy of the disk or volume. DMDE, Recuva, MiniTool are some of the best ones w/ a Windows GUI. SystemRescue is great stuff, bootable Linux-based system. Photorec is good, command line interface however ...Hey, speaking of command line Microsoft released their own file recovery tool finally, good on them, like I said command line only.
Anything that stuff can't recover, is gone forever assuming there's no copy of it elsewhere, just as if something existed only as a single paper copy and then got chucked into a volcano. Software isn't magic, it's just instructions to a machine.

Final step: set up automatic backup of stuff you care about. Remote cloud storage is cheap these days. Ideally also make "physical backups" onto other storage devices. Set a schedule for yourself. (With a bit of work and resources you could also set up a "live" "backup appliance" server for yourself to do automatic backups in the background.) If you have physical objects precious to you, you likely do something like buy a safe or rent a safe deposit box for them right? Personal "cloud" recommendation: pCloud, Swiss company, great pricing and features. (Not a huge ad budget.) It's difficult to have too many copies of stuff you care about unless you get really crazy. --Slowking Man (talk) 18:14, 20 October 2024 (UTC)[reply]

Ah, also, as the file recovery article mentions, if a file's data is merely partially overwritten but not fully, the not overwritten stuff often can be recovered. Difficulty: sometimes automated tools (like the ones mentioned) can handle it and that's all you need. But if it's absolutely necessary that every last byte which can be, is recovered, the real hard cases can require understanding the fine details of computer data and storage and file formats, binary or hexadecimal arithmetic, dropping into a hex editor and manually "bit-twiddling" to repair corrupted files all that fun exciting stuff. Familiar with the terms big-endian and little-endian? (Another thing pros can take care of, though the ones who do understand that stuff and do it well tend in the pricier direction. Need someone with a bit more expertise than a youngster with a laptop who knows how to pop open a copy of Acronis and click the buttons.) Slowking Man (talk) 18:26, 20 October 2024 (UTC)[reply]

Thanksss, I will try it tomorrow. and will report the results. For the time being, I've only carried out the first step, because it seems to be the most urgent one. HOTmag (talk) 19:07, 20 October 2024 (UTC)[reply]

I previously noted that "unformat" isn't a thing anymore. File recovery is not "unformat". It allows you to collect files. Often, the file names are lost, but you can still get the files, rename them, and place them on another drive. It simply isn't unformatting. You are not unformatting the hard drive. You are finding files that are still intact on the previously formatted drive and copying them. My experience is that people do not want that. They don't want a long list of every file they had on their computer (all the dll files and exe files and tmp files...). They want to literally unformat the hard drive and have it be exactly as it was before they formatted it. For that reason, I stated that unformatting does not exist. What I do when a person finally gives up on unformatting is I look for all docx, xlsx, pdf, etc... files and place them on a USB drive. They aren't happy about it, but at least it gets them their files back. 12.116.29.106 (talk) 15:41, 22 October 2024 (UTC)[reply]

With some of the most widely-used "Unix-style FSes", such as ext2/3/4, if you're lucky and the superblock simply got stomped on somehow (like something writing to the start of the volume (triple-check those dd commands before executing, folks)), you can just copy one of the backup copies from the intact part (or from a FS backup copy!) which could be thought of as a kind of "unformat" (in fact e2fsprogs has a command to do this). (And then fsck for good measure in fact I think the fs code might force this when mounting.) And F2FS is a log-structured FS so all the FS metadata that didn't get overwritten is there intact, just repair the FS to a consistent state and good to go.

The reason that doesn't work on NTFS is the core "map" to the file data on-drive, and a lot of file metadata including file names, is centralized in the MFT. Unless the MFT is at least partly-intact and can be rebuilt, *boop* all that's gone. In a "Unix FS" by contrast, file metadata incl names is stored in the directory files. For /foo/bar, the root directory file contains the file metadata entry for foo (of the "directory" type), then foo's file data contain the metadata entry for bar giving you what inode number the "bar" link points at. ("Low-level", a file, to the FS, exists as an inode and the data the inode points at. The inode # is the unique ID. File names are just "link" entries in dirs that point at inodes. Hence why a file can be ref'd by multiple hard links: they just point to the same inode #.) The sblock just defines the basic fs layout (for ex block size).

(If an ext4 fs was reformatted w/ default opts but never mounted, only the sblocks and group descriptor tables will be "re-initalized". The inode structures are initalized "lazily" in the bkgr by the kernel, post-mount. With a little FS surgery it's possible for someone who knows how to reconstruct the vital parts of the prior sblock, and e2fsprogs will take care of the rest) --Slowking Man (talk) 00:50, 23 October 2024 (UTC)[reply]