From 0a0ebe7a41792e71e725e619b86266121e306da6 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 17 Jun 2005 13:16:00 +0000 Subject: [PATCH] (usage): Clarify that shred works on an ext3 file system as long as it's not in data=journal mode. Tiny change by Mark Melahn. --- src/shred.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/shred.c b/src/shred.c index 02b9751..90e47d7 100644 --- a/src/shred.c +++ b/src/shred.c @@ -190,7 +190,7 @@ CAUTION: Note that shred relies on a very important assumption:\n\ that the file system overwrites data in place. This is the traditional\n\ way to do things, but many modern file system designs do not satisfy this\n\ assumption. The following are examples of file systems on which shred is\n\ -not effective:\n\ +not effective, or is not guaranteed to be effective in all filesystem modes:\n\ \n\ "), stdout); fputs (_("\ @@ -209,6 +209,14 @@ not effective:\n\ \n\ * compressed file systems\n\ \n\ +In the case of ext3 filesystems, the above disclaimer applies\n\ +(and shred is thus of limited effectiveness) only in data=journal mode,\n\ +which journals file data in addition to just metadata. In both the\n\ +data=ordered (default) and data=writeback modes, shred works as usual.\n\ +Ext3 journaling modes can be changed by adding the data=something option\n\ +to the mount options for a particular file system in the /etc/fstab file,\n\ +as documented in the mount man page (man mount).\n\ +\n\ In addition, file system backups and remote mirrors may contain copies\n\ of the file that cannot be removed, and that will allow a shredded file\n\ to be recovered later.\n\ -- 2.7.4