Microsoft adds WINFR file undeletion tool to the Microsoft Store

Although it isn’t yet built into Windows, Microsoft has finally released its own file undelete tool—it’s called Windows File Recovery, and it works with the newest builds of Windows (variously known as 20H1, 2004, and 19041). We were pretty excited to see this tool has become available—even though proper system administration means frequent backups, which render this tool unnecessary. In the real world, proper system administration and frequent backups are a lot less common than we might wish.

The lack of a proper file undeletion tool in Windows means that many of us have been hoarding one of a handful of old shareware or freemium third-party utilities capable of scanning disks and looking for remnants of deleted files. The “hoarding” part is unfortunately necessary because finding one of those utilities means sorting through stacks of scam apps targeting desperate users—and frequently, you can’t be certain whether you’ve found one of the good ones or one of the scams until after you’ve installed it (hopefully, inside a sandbox or isolated VM).

Installation

It’s great news that Microsoft is finally bringing that capability in-house—but the tool certainly could be easier to find. When we looked for Windows File Recovery by name on Bing, in a freshly installed Windows 10 2004 VM, we got buried under pages of ads for other things.

Moving onto the Microsoft Store, the experience was no better—when searching for its exact name, we couldn’t find the Windows File Recovery tool until we’d filtered our results first to Apps only, then to Tools & Utilities only.

Once we’d finally found the tool and verified that we met the system requirements, installation was a click away.

On today’s episode of “Ars Deletes a File”

Unlike most of the third-party “undelete” utilities winfr supersedes, it’s a command-line utility only—users won’t get a graphical interface to help them wade through their drive. It’s also incredibly picky about where it recovers files to—you’ll need a separate storage volume, such as a USB thumb drive, to restore any files to. Attempting to just undelete a file in place earns you a stern rebuke from winfr, and there doesn’t appear to be any way to override this behavior.

More importantly, we were unable to get winfr to restore a just-deleted file from our VM’s C drive at all. In our first attempt, we created and deleted an empty text file, but winfr couldn’t find it. Thinking that perhaps the tool “helpfully” ignored empty files, we tried again, and this time, we put a bit of actual data in our sacrificial text file. There was no change in the results.

To make certain we weren’t missing something, we tried again—this time with a large NASA image saved to the Pictures directory. First we deleted the file using del *.jpg at a CMD prompt, and then we tried to recover it to a USB drive with winfr C: F: -n \Users\Jim\Pictures. Still no luck. We thought perhaps the filter was a problem, so we removed it, this time asking for all recently deleted files from the C drive, using a simpler winfr C F:—still with no luck.

Now we wondered if there was something magic about the DEL command that made Windows think it should shred those files rather than simply unlinking them—so after downloading our test image again, this time we tried deleting it from the GUI using shift-delete in File Explorer—still with no change in the results.

SSDs, TRIM, and your deleted files

After some more frustrated digging, it dawned on us that our VM’s C drive was stored on a ZFS pool which was itself living on a set of SSDs—and that perhaps the TRIM functionality of those disks was shredding our data faster than we could recover it. In order to test this hypothesis, we created a new backing file on a second, rust-based pool, fed it to our VM as a separate X drive, and tried again.

After deleting our third sacrificial JPG from the new X drive using DEL on the command line, we tried winfr again—and this time, it worked perfectly; our freshly deleted JPG showed up in all its glory on the “USB” drive mounted as F, just as we’d requested.

There are a couple of important lessons to be learned here. The more obvious one is that most people likely can’t benefit from winfr (or other undelete applications) at all—the vast majority of modern systems store C on an SSD with TRIM functionality available.

The less obvious takeaway is that winfr may have problems with some Shingled Magnetic Recording drives as well. Both SSDs and SMR disks use zoned access, with smart firmware and a virtual drive map rather than literal direct addressing. This in turn requires use of the TRIM command, which notifies drive firmware when a block has been deleted—which in turn allows the drive to treat that block as unused space rather than as precious data which must be preserved.

We repeated our test on yet another virtual drive, this time backed by an SMR disk—the Western Digital Red 4TB EFAX. On the plus side, winfr successfully retrieved the file from the SMR Red—but on the minus side, it required nearly 20 seconds to do so, while the non-SMR disks had managed it in only two seconds. This may be another application that’s not well-suited to SMR disks, which are increasingly found in desktop channels targeted to budget-minded consumers.