From LQWiki
Jump to navigation Jump to search

The conventional wisdom that file-overwrite utilities such as shred and wipe will not necessarily destroy file contents on journaling filesystems (ext3 in default (ordered) mode, in particular), as stated in their man pages, seems to be incorrect. This seems (?) to originate from:

1) Caution due to early versions of ext3 which used journal data mode instead of the (current) default ordered mode, where only metadata is written to the journal. Even if the metadata is sensitive it will be quickly overwritten during normal use of the filesystem.

2) A possible tendency to confuse log-structured filesystems such as Reiser with journalled filesystems like ext3. Log-structured filesystems are an entirely different matter.

There is little clarity on this issue on the web. If the above is true (and it looks as if it is), then it would be f!@#$g nice if man wipe and man shred would !@#$% say so.

Also, ext3 is actually supposed to be *more* difficult to recover deleted files from than ext2 - in fact, the ext3 FAQ says it can't be done at all. Flying in the face of this there are commercial programs for Windows that claim to be able to recover deleted files from ext3 eg Stellar Phoenix Linux. Of course here we are talking about data recovery within normal resources, not getting the electron microscope out and peeling data off the disk bit by bit: "..even the FBI can't get it back .." is not necessarily true.

I'm sure everyone would appreciate either a confirmation or refutation (not disinformation) of the above concerning ext3 and wipe/shred from forensic and filesystem experts please, and an ensuing modification to man wipe and man shred.


As I interpret this, "wipe" will work with any of these journaling modes to overwrite data at its primary location on the disk. However, with "data=journal" there may be another copy of the data in the journal that "wipe" would not reach. > I am curious if anyone knows why utilities such as > 'GNU shred' (part of coreutils) and 'wipe' say they > are not effective on journalled file systems- > especially EXT3.

I don't know why they would say this. With very early versions of ext3 (or filesystems mounted with data=journal) all data writes would also go to the journal, so you would get two copies of your data on disk. The "shred" overwrite would in theory only erase the copy in the filesystem. It is also possible to get a copy of the last partial page of a truncated file being put into the journal.

Of course, this neglects the fact that the journal is continually being overwritten so the only time there might be data in the journal (in the non-default data=journal mode) is after it was just written to disk. In normal filesystem usage this would be overwritten hundreds of times, and the user-space overwriting tool would itself cause the journal to be overwritten in this case (taking relative sizes of files and journal into account).

I know reiser4 on the other hand is a log-structured filesystem, so overwriting a file has no guarantee that even the data blocks will be overwritten.

...shred will work just fine on a journaled filesystem. The journal in a journaled filesystem guarantees the integrity of the filesystem structures (meta-data) NOT the data stored in the filesystem. Some journaled filesystems CAN also provide data journaling, but only at a *significant* performance cost. In other words, the journal will have no effect on "shred".

Also, the "shred" program performs all of it's I/O operations synchronously; that is, everything happens on the disk right then and is not cached. This is a critical feature whether one is using either a journaled or non-journaled filesystem. --