Fuji

Appearance

Erase ​

Deleting a file does not erase it. The file system forgets where the file was, and the bytes stay on the drive until something else is written there. Erasing means writing over them first, and the history of erasing is a search for where that write actually lands. Fuji's Delete is built on what the search found: it erases a file quickly and for good, with nothing to set.

Where the write lands ​

What deleting does, 1982 to 1991 ​

Undelete came before erase. In the June/July 1982 issue of PC Magazine, Peter Norton advertised UNERASE, which "Recovers erased files, even if partly over-written," and a review of his utilities in PC Tech Journal the next year said how it could, both as transcribed in the PCjs history of the Norton Utilities: "When a file is erased, only two things really happen to it: the first letter of the file name is replaced by hex 'E5', which means that the directory entry is now available for use by another entry, and the allocated space in the FAT is considered free to be written on by other data." In 1991 MS-DOS 5 shipped an undelete of its own, under Central Point Software's copyright, and Microsoft's manual for it told every user what deleting does:

When you delete a file, MS-DOS does not delete the data in the file. Instead, it marks the file as deleted so MS-DOS can reuse the area of the disk that was occupied by the deleted file. The data remains on the disk until MS-DOS records the data of another file in the same region of the disk.

File systems still delete this way. In exFAT, which many portable drives come formatted with, as Seagate's do, the specification marks a deleted file's directory entry "not in use" and each of its clusters "available for allocation," and NTFS marks a deleted file's entries in its master file table "as free and may be reused." Neither touches the clusters that hold the file's contents.

Wiping, 1984 to 1994 ​

The programs that taught people a deleted file could come back sold the cure as well. Version 3 of the Norton Utilities, in 1984, added WipeFile and WipeDisk, which its manual introduced with the reason: "Erasing files, or formatting disks does not guarantee that confidential data is thoroughly destroyed." They wiped "by over-writing it with blank information," one pass of zeros. Four years later the manual for version 4.5 asked for more, on the authority of a Department of Defense manual: "The latest DOD specifications (DoD 5220.22-M) specify that the 0/1 pattern should be repeated three times, followed by a write of a random value, then a verification of the last write." Three rounds of ones and zeros and a last value make seven writes, the count later programs offered under the same name.

In 1991 the National Computer Security Center's guide to data remanence split the threat in two, an attack from the keyboard and an attack in a laboratory, and found the first easy to stop: "a single overwrite of a file or all system storage, if the circumstance warrants such an action, is adequate to ensure that previous information cannot be reconstructed through a keyboard attack."

In 1994 Berkeley's 4.4BSD-Lite put the overwrite into rm itself. With its new -P option, "Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted," as the manual page says, and the code said what that assumed. It called itself "a cheap way to *really* delete files" that "assumes a fixed-block file system," and warned, "In a logging file system, you'll have to have kernel support."

What a disk remembers, 1993 to 1996 ​

The evidence that an overwrite might not be enough came from a microscope. At the University of Maryland, Romel Gomez, Amr Adly and Isaak Mayergoyz, with Edward Burke of the Laboratory for Physical Sciences, modified "a conventional scanning tunneling microscope": "The fine-wire probe that is used to image surface topography was replaced with a flexible magnetic probe." Their report to a NASA technology conference in 1993 said what it had found on recorded disks: "The most important discovery of our work is that under certain conditions all of the overwritten data can be retrieved."

Peter Gutmann worked out what an erase would have to do against that. The documentation of his Secure FileSystem, SFS, an encrypted disk for DOS, already gave in March 1995 a sequence of "35 consecutive writes to erase data." In July 1996 he presented the whole argument as "Secure Deletion of Data from Magnetic and Solid-State Memory" at the Sixth USENIX Security Symposium in San Jose, and it began with why an overwrite on a magnetic disk is never complete:

The problem lies in the fact that when data is written to the medium, the write head sets the polarity of most, but not all, of the magnetic domains. This is partially due to the inability of the writing device to write in exactly the same location each time, and partially due to the variations in media sensitivity and field strength over time and among devices. In conventional terms, when a one is written to disk the media records a one, and when a zero is written the media records a zero. However the actual effect is closer to obtaining a 0.95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one.

A drive's own circuitry reads both as ones, but "using specialised circuitry it is possible to work out what previous 'layers' contained," and the paper concludes that "each track contains an image of everything ever written to it, but that the contribution from each 'layer' gets progressively smaller the further back it was made."

Erasing that image means flipping every magnetic domain back and forth, and a drive does not write a file's bits as they are. It writes them through a run-length limited code, "used to ensure that transitions aren't placed too closely together, or too far apart," so the bytes a program chooses are not the pattern that reaches the platter. Gutmann worked backward through each encoding of the time, MFM, (1,7) RLL and (2,7) RLL, to the bytes that would flip what each one wrote: "We now have a set of 22 overwrite patterns which should erase everything, regardless of the raw encoding." Four passes of random data before them and four after, with the fixed ones in random order, made thirty-five. For the newest drives, which read through partial-response maximum-likelihood signal processing, PRML, there was no encoding to aim at, and the paper gave them one line: "A good scrubbing with random data will do about as well as can be expected."

Erasers, 1997 to 2006 ​

On Windows, Sami Tolvanen released Eraser in 1997, free software whose patterns, its page said in 2000, "are based on Peter Gutmann's paper." It spread fast: "In 1999, over 150 000 copies were downloaded from ZDNet and this site alone," and when he handed it on in November 2001, "nearly a million copies have been downloaded." When The New York Times reviewed erasing software for its readers in May 2002, it listed programs priced from $19 to $149.95, and one that cost nothing: "Eraser By Sami Tolvanen, free." Garrett Trant took over after version 5.3, and Eraser 6, whose source names Joel Low as its original author, arrived in December 2009 with, in its release notes, "a completely revamped user interface." Its erasure methods number thirteen, from one pass of pseudorandom data to Gutmann's thirty-five, and most are named for a standard: two versions of the Department of Defense's 5220.22-M, Germany's VSITR, Britain's HMG IS5, Russia's GOST P50739-95, the Royal Canadian Mounted Police's TSSIT OPS-II, and a seven-pass method from Bruce Schneier's Applied Cryptography.

Colin Plumb, whom Gutmann's paper thanks, wrote shred for Unix between 1997 and 1999, and Jim Meyering merged it into the GNU file utilities. It is in GNU coreutils today, and so, in Gutmann's words, "in pretty much every Linux distro."

Mark Russinovich announced SDelete in the Systems Internals Newsletter of May 15, 1999, and its documentation reads as a catalog of the places NTFS keeps bytes out of a plain overwrite's reach, with the way SDelete reaches each. A file NTFS compresses, encrypts or stores sparsely is "managed by NTFS in 16-cluster blocks," and a write to it lands in new clusters, so overwriting it "will not succeed in deleting the file's contents from the disk"; SDelete asks the defragmentation API which clusters hold the file, opens the disk for raw access, and overwrites those clusters directly. A small file, "typically, 900 bytes or smaller" in Microsoft's account of NTFS, lives inside its record in the master file table, so SDelete cleans the free records by creating files that just fit in one until NTFS refuses to make another. And a name outlives its file in the directory, so SDelete renames the file 26 times, "each time replacing each character of the file's name with a successive alphabetic character."

Apple added Secure Empty Trash to Mac OS X in Panther, in 2003, "a feature called Secure Empty Trash, which overwrites the space left behind by deleted files," as Macworld described it, and shipped srm, whose manual page says that unless told otherwise "the 35-pass Gutmann algorithm is used." Disk Utility offered the menu too. Apple's note on its erase options for Mac OS X 10.4 said of one choice, "The 7-Pass Erase option conforms to the DoD 5220.22-M specification. This specification calls for three passes, but Disk Utility performs seven," and of another, "The 35-Pass erase option uses the Gutmann algorithm." For a whole drive, Darik's Boot and Nuke, DBAN, booted a computer from a disc, from 2003 on, to wipe its drives whole.

NIST's guidelines later summed up the practice: "In the past, hard drives were often erased using multiple overwrite passes (e.g., based on DoD 5220.22-M) with specific binary patterns (e.g., a pattern of all zeros). The number of passes ranged from a single pass to as high as 39." The manual itself, the National Industrial Security Program Operating Manual, had moved on, in a footnote's words: "In 2006, DoD removed overwriting specifications from NISPOM."

The tools were many, and little used. Simson Garfinkel and Abhi Shelat bought 158 used hard drives between November 2000 and August 2002, and their study set "more than 50 tools licensed for a single computer system" against what the drives still held: "Of the 129 drives that we successfully imaged, only 12 (9 percent) had been properly sanitized by having their sectors completely overwritten with zero-filled blocks."

One pass, 2001 to 2009 ​

Gutmann came back to the paper between 2001 and 2003, when an epilogue appeared on its page, missing from a copy archived in August 2001 and there in one from February 2003. It says what the thirty-five passes were and were not:

In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper).

A drive needs only the passes for its own encoding, "and you never need to perform all 35 passes," and "For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do."

Others questioned the recovery itself. In 2003 Daniel Feenberg of the National Bureau of Economic Research went through the paper's references in a response to Gutmann, and found that "Gutmann doesn't cite anyone who claims to be reading the under-data in overwritten sectors." The microscope images of overwritten bits the paper drew on showed a handful of them: "The total number of bits seen was 6 in one photo and 8 in the other." He passed on Charles Sobey's estimate that it "would take more than a year to scan a single platter," and concluded that "Gutmann's claim belongs in the category of urban legend."

The University of California, San Diego, moved the erase into the drive. Its Center for Magnetic Recording Research, under Gordon Hughes, wrote that "CMRR requested the SE command now in the T13.org ATA specification," a Secure Erase command the drive runs on itself, which must "write binary zeroes to all user accessible data areas." Its enhanced form reaches further, to what NIST's guidelines quote the standard as calling "sectors that are no longer in use due to reallocation," the ones a drive retires as they fail and no program can address any more. The center's HDDerase issued the command from 2004. Its tutorial on disk sanitization, by Hughes and Tom Coughlin, reported what its testing found: "in today's drives, multiple overwrites are no more effective than a single overwrite," and "even three overwrites can take more than a day to erase a large capacity hard disk drive." The National Institute of Standards and Technology's first guidelines for media sanitization, in 2006, said the same: "Studies have shown that most of today's media can be effectively cleared by one overwrite," and "for ATA disk drives manufactured after 2001 (over 15 GB) clearing by overwriting the media once is adequate to protect the media from both keyboard and laboratory attack."

The tools followed. Coreutils 7.1, in 2009, records in its news that "shred: now does 3 overwrite passes by default rather than 25," and shred's manual says why: "By default the patterns are designed for best effect on hard drives using now-obsolete technology; for newer devices, a single pass should suffice."

Flash, 2011 to 2015 ​

A later epilogue to Gutmann's paper begins: "This paper covers only magnetic media and, to a lesser extent, RAM. Flash memory barely existed at the time it was written, and SSDs didn't exist at all." Flash breaks the assumption every overwrite rests on. In Samsung's words, "With NAND flash, the stored data cannot be overwritten when new data is stored or erased." A flash drive writes in small pages and erases only in large blocks, so a rewrite goes to a fresh page, and a flash translation layer inside the drive moves the address to it. The old page stays where it was, marked stale, until garbage collection, which "secures free blocks by collecting valid pages into a single location and erasing the blocks consisting of invalid pages," gets around to its block. Every drive also holds spare flash for this work, which "can only be accessed by the SSD's controller and not by the host."

In 2011 Michael Wei, Laura Grupp, Frederick Spada and Steven Swanson of UC San Diego measured what that does to an erase, with a method of their own: they wrote known patterns, ran an erasing technique, then would "dismantle the drive, and extract the raw data directly from the flash chips using a custom flash testing system." Their paper at USENIX's conference on file and storage technologies reached three conclusions:

First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

The drives they opened held "between 6 and 25% more physical flash storage than they advertise," and after they wrote a thousand small files, one drive "contained up to 16 stale copies of some of the files." Every method of erasing a single file failed: "between 4% and 75% of the files' contents remained on the SATA SSDs. USB drives performed no better: between 0.57% and 84.9% of the data remained." Gutmann's thirty-five passes left 0.8 to 4.3% of a file on the SSDs, and 71.7% on a USB drive. And one drive's own erase command "reported that sanitization was successful, but all the data remained intact. In fact, the filesystem was still mountable." TRIM, the command a computer sends to tell a drive which blocks it no longer uses, "does not have any reliable effect on data security," and the Linux kernel's own driver for ATA drives says why: "TRIM is only advisory, however, and the device is free to silently ignore all or parts of the request."

A memory card or a thumb drive hides the most. Andrew "bunnie" Huang, taking apart memory cards in 2013, wrote that "all flash memory is riddled with defects — without exception. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions," so "every flash memory disk ships with a reasonably powerful microcontroller" to run them. The flash inside a card "can be anything from high-grade factory-new silicon to material with over 80% bad sectors," and the same holds, he added, for "USB flash drives and SSDs."

The same epilogue of Gutmann's draws the consequence: "SSDs are a totally different technology than magnetic media, and require totally different deletion techniques. In particular you need to be able to bypass the flash translation layer and directly clear the flash blocks." His list of the programs he uses ends, "To erase SSDs.... well, you're on your own there." Apple took Secure Empty Trash out of OS X El Capitan in 2015, and its security notes for that release give the reason: "An issue existed in guaranteeing secure deletion of Trash files on some systems, such as those with flash storage. This issue was addressed by removing the 'Secure Empty Trash' option." Disk Utility offers no secure erase for an SSD, and points instead to "FileVault encryption when you start using your SSD drive." An Apple engineer, answering a developer in 2026, gave the reason for external drives: "we (Apple) do not control the block remapping layer of the drive, and so knowing exactly when a particular block's prior contents have been zeroed is very challenging. So in the interest of not wanting to offer any false promises, it was removed."

Writing somewhere else, 2001 to 2020 ​

File systems had begun writing somewhere else before flash did. In 2001 Steven Bauer and Nissanka Priyantha told the USENIX Security Symposium that a program could not erase a file on its own, "Any implementation of secure deletion at the user-level will be inadequate," and their paper built the erase into Linux's ext2 file system instead, behind a file attribute. The attribute is still there, and chattr's manual still says it is "not honored by the ext2, ext3, and ext4 file systems as implemented in the current mainline Linux kernels." Shred's manual opens its caveats with the assumption every overwrite depends on:

The shred command relies on a crucial assumption: that the file system and hardware overwrite data in place. Although this is common and is the traditional way to do things, many modern file system designs do not satisfy this assumption.

Its exceptions include file systems that journal data, "Btrfs, NTFS, ReiserFS, XFS, ZFS" among them, "File systems that make snapshots," and "Compressed file systems." Apple's APFS is built that way: "Apple File System uses copy-on-write to avoid in-place changes to file data, which ensures that file system updates are crash protected without the write-twice overhead of journaling," says Apple's guide. A clone, APFS's copy of a file that takes no space, shares its blocks with the original, and "Modifications to the data are written elsewhere," in Apple's description. Time Machine "saves one snapshot of your startup disk approximately every hour, and keeps it for 24 hours," and every block a snapshot holds outlives the file's deletion. Fedora made Btrfs, another copy-on-write file system, its desktop default with Fedora 33, and compressed it with Fedora 34. And Windows' Volume Shadow Copy Service, which System Restore runs on, copies a block before it changes: "Each block to be modified is read and then written to the volume's shadow copy storage area," Microsoft explains, which "preserves a copy of the data block on the original volume before the change overwrites it."

Spinning disks grew translation layers of their own. Shingled magnetic recording, as Western Digital describes it, "removes the gaps between tracks by writing the tracks in an overlapping manner, forming a pattern similar to the shingles on a roof," which fits more tracks on a platter and means a track cannot be rewritten without disturbing the one it overlaps. A drive-managed shingled drive "handles the SMR sequential-write constraint internally (in the disk firmware)," and is "transparent to hosts." In 2015 Abutalib Aghayev and Peter Desnoyers set out to see what such a drive does inside, and their paper, Skylight, watched it directly, "using a high-speed camera through an observation window drilled through the cover of the drive." Seagate's 5 TB and 8 TB shingled drives kept "a persistent disk cache of 20 GiB and 25 GiB," which "contains copies of recently-written data," in front of bands of 15 to 40 MiB, and cleaned the cache later by rewriting "every band whose data was overwritten." A rewritten sector goes to the cache, and the old one stays in its band until cleaning reaches it. Seagate lists which of its bare drives are shingled, its 8 TB BarraCuda among them, and that list names none of its external drives.

Keys, 2002 to 2025 ​

The way out was already in Eraser's own frequently asked questions, for version 5.3, Tolvanen's last. To "Overwriting is the key to ultimate security, isn't it?" he answered "Wrong," because overwriting cleans up after a leak, and "the best way to deal with this is to prevent the data from getting written to the disk in the first place," with strong encryption. Data written encrypted can be erased without finding it: destroying its key leaves only ciphertext behind, wherever the stale copies are.

NIST built that into its revised guidelines of 2014, which sort sanitizing into three levels. Clear "applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques"; Purge renders "Target Data recovery infeasible using state of the art laboratory techniques"; Destroy does as much and leaves the media unusable. Flash moved a familiar tool down a level: "Whereas ATA Secure Erase was a Purge mechanism for magnetic media, it is only a Clear mechanism for flash memory." Cryptographic erase, which the 2025 revision defines as applying sanitization "to one or more keys providing confidentiality protections for the encrypted target data, making recovery of the decrypted target data infeasible," is a Purge.

A key is only as good as the code that keeps it. In 2019 Carlo Meijer and Bernard van Gastel of Radboud University examined drives that encrypt themselves in hardware, and found that "For many models, these security weaknesses allow for complete recovery of the data without knowledge of any secret (such as the password)." They found the wear leveling that defeats an overwrite at work on the keys as well: "Older copies of a sector remain stored until overwritten." That September Microsoft changed BitLocker's default: "Now, the default is to use software encryption for newly encrypted drives." Apple keeps its keys in its own silicon. On a Mac with Apple silicon or the T2 chip, internal storage is encrypted even with FileVault off, its key "protected only by the hardware UID in the Secure Enclave," and "When deleting a volume, its volume encryption key is securely deleted by the Secure Enclave," which "renders the volume cryptographically inaccessible," in the words of Apple's platform security guide.

The 2025 revision closed the old argument in its list of changes: "The 'clear' method was clarified such that multi-pass overwrite is not needed. This counters the obsolete DoD 5220.22-M language that mandates a certain number of overwrite passes and patterns." And it names, in a footnote, the case a file manager meets: "An example of selective sanitizing is sanitizing the contents of a single file that is encrypted with a unique key using CE." Erasing part of a drive rather than all of it carries a risk the same document states: it "can be difficult to verify" that data stored on one part "did not spill over into other areas," such as "remapped bad blocks or overprovisioning."

What the record settles ​

Deleting removes a name. The bytes stay until something writes over them, and undelete programs have read them back since 1982.

On a magnetic disk one pass is enough. The seven passes trace to Norton's reading of a Defense Department manual in 1988 and the thirty-five to the drive encodings of 1996, and the author of the thirty-five said never to run them all. Every pass past the first costs time: three can take more than a day on a large drive.

Every layer that stopped writing in place moved the old bytes out of an overwrite's reach. A copy-on-write file system writes the new copy to a new block, a snapshot exists to keep the old one, a flash translation layer writes the new copy beside the old, a shingled drive writes it to a cache, and a drive retires a failing sector with its contents still in it.

A drive's own erase commands work on the whole drive, and a drive can report success and keep everything.

Encryption turned erasing into destroying a key, and NIST's newest guidelines name erasing one file by destroying its own key.

And the tools grew menus while the knowledge moved toward fewer choices: one pass on a magnetic disk, and on everything else a key to destroy.

Fuji's Delete ​

Fuji's Edit menu carries a file manager's commands, cut, copy and paste among them, and two ways to remove a file. Move to Trash puts it in the Trash or the Recycle Bin, where the user can take it back. Delete erases it, and is built to four guidelines:

  • Permanently set, with no setting to forget.
  • Configuration free, with no complex choices to weigh.
  • Secure, even against a highly sophisticated adversary.
  • Designed for current consumer hardware: Windows 10 and 11, recent Macs and the popular Linux desktops, and the drives people use with them, from the SSD inside a laptop to a large USB disk and a thumb drive.

One pass, flushed, then the name ​

Delete writes over every byte of the file once with random bytes, makes sure they have reached the drive, writes over the file's name, and removes it. The heart of it is in copper/src/erase.rs:

rust
let allocated = allocation(&file, &held);
overwrite(&mut file, held.len(), allocated)?;
file.sync_all()?;
let named = rename(Path::new(path));
let _ = file.sync_all();
#[cfg(unix)]
if let Some(folder) = named.parent() { let _ = File::open(folder).and_then(|folder| folder.sync_all()); }
drop(file);
std::fs::remove_file(&named).map_err(|e| std::io::Error::new(e.kind(), format!("erase: {path}: written over but not removed: {e}")))?;

One pass is what the record settled on for a magnetic disk, from CMRR's testing to NIST's guidelines and Gutmann's own epilogue, and random bytes are what his paper recommends for a drive whose encoding nobody can aim at. They come from BLAKE3's output stream under a key of 32 bytes from the operating system, new for every file, so no two erasures write the same bytes. The pass runs on past the end of the file to the end of its last cluster, which the file system reports as the file's allocation, because the slack between the two keeps whatever was written there before, the tail of a longer version of the file among the likely things; shred's manual says it rounds a file "up to the next multiple of the file system block size to fully erase the slack space in the last block of the file" for the same reason. The cost is one write of the file, rounded up to its last cluster, the least any overwrite can cost.

The flush matters as much as the pass. An overwrite waits in the operating system's memory until it is flushed to the drive, and a file removed before then need never have it written at all. So Fuji flushes before it removes anything, on the Mac through F_FULLFSYNC, which, in the words of macOS's manual page for fcntl, "Does the same thing as fsync(2) then asks the drive to flush all buffered data to the permanent storage device."

The name goes last. Fuji renames the file to random lowercase letters, as many as its name had, and removes it under that name. On exFAT, the file system of many thumb drives and portable disks, Linux's driver rewrites a name in place when the new one needs no more directory entries than the old, which a name of the same length never does, so the old name is gone from the folder. FAT32 writes a long name into new entries and marks the old ones deleted, and a copy-on-write file system writes it to a new place, so there a name can outlive its file in the folder's own records.

What Delete leaves alone ​

Some files are not the file's alone to erase, and for those Delete does what a plain delete does. A symbolic link is removed, and the file it names is untouched. A file with a second hard link loses one of its names, and its bytes stay with the other. A file a cloud service holds, an iCloud Drive file not downloaded to the Mac or any file OneDrive keeps on Windows, is removed without the overwrite, since writing to it reaches through the service, which would upload the random bytes as a new version; the service keeps its own deleted copy for a while, OneDrive "for up to 30 days" in its recycle bin for a personal account, and iCloud until files "are removed from Recently Deleted after 30 days," as Apple says.

A move to another drive has to copy, and Fuji erases the original once the copy has reached its new drive, so moving a file leaves nothing behind on the old one.

Where it reaches ​

On a spinning disk whose file system writes in place, NTFS, exFAT, FAT32, or ext4 in its default mode, where shred's manual says "shred works as usual," the file's old bytes are gone, even to a laboratory, as CMRR's testing and NIST's guidelines found. A shingled drive keeps the old copy in its band until it cleans that band, and then it is gone as well.

On every drive, the overwrite changes what the drive hands back. An undelete program or a forensic image reads random bytes where the file was, through the same interface every program on the computer uses, and that is how a lost thumb drive or a sold laptop gets read.

And Fuji keeps no copy of its own. It writes no thumbnail to disk and keeps no index and no list of recent files, its settings name no file, and its log, which stays off unless the user turns it on, is the only place it could write a name.

Where nothing reaches ​

Below a flash drive's interface, the old pages stay until the drive's garbage collection erases them, and no program can reach them, Fuji included. There the protection is a drive encrypted from the start, so that whatever pages remain are ciphertext. A Mac with Apple silicon or the T2 chip always encrypts its internal storage, and from macOS 26.4 FileVault is on by default, "which automatically provides users the full protection of entangling the encryption key hierarchy with their password." Windows starts device encryption on a clean install of a qualifying PC, but Microsoft notes that "If a device uses only local accounts, then it remains unprotected even though the data is encrypted," and that it "doesn't encrypt external/USB drives." Ubuntu's installer offers to encrypt the whole drive. Encryption turned on later protects only what is written after it: data "added and then deleted before turning on FileVault isn't encrypted and may be recoverable with forensic data recovery tools," in Apple's words. A thumb drive is encrypted only if its owner encrypts it.

On a file system that writes elsewhere, the overwrite lands in new blocks, and the old ones are freed. Apple says APFS "uses copy-on-write to avoid in-place changes to file data"; Btrfs, Fedora's default, does the same, and so does NTFS for a file it compresses, encrypts or stores sparsely. An internal SSD is then told the old blocks are unused, APFS issuing TRIM, in Apple's words, "asynchronously from when files are deleted," and a spinning disk keeps them until something reuses the space.

Copies made elsewhere are out of any delete's reach: Time Machine's local snapshots, each kept for 24 hours, Windows' restore points, backups, and a cloud's version history. So are the derivatives a system keeps of the files it has shown: Windows' thumbnail cache, the search indexes, and macOS's Quick Look cache, where thumbnails, Objective-See found, "stay there even if you delete these files."

A reader who needs more than any delete can give has three things to do beyond Fuji: encrypt each drive before the files arrive, keep sensitive files off flash that nobody encrypted, and count the snapshots, backups and clouds that keep copies of their own.

Nothing to set ​

Fuji does every part of erasing that a program can do, the same way every time, on every drive. There is no method to choose, no number of passes to set, and no manual to read first. When you delete a file with Fuji, it's erased quickly, permanently and securely, with nothing to set or worry about.

Sources ​

Every address below was fetched on October 27, 2026.

Fuji licenses the text of this page under Creative Commons Attribution 4.0 International.