From 015de7293183b238127849af2bc62e32c1d61c19 Mon Sep 17 00:00:00 2001 From: Terts Diepraam Date: Fri, 10 Mar 2023 20:49:26 +0100 Subject: [PATCH] shred: move help strings to markdown files --- src/uu/shred/shred.md | 47 +++++++++++++++++++++++++++++++++++++ src/uu/shred/src/shred.rs | 49 ++++----------------------------------- 2 files changed, 52 insertions(+), 44 deletions(-) create mode 100644 src/uu/shred/shred.md diff --git a/src/uu/shred/shred.md b/src/uu/shred/shred.md new file mode 100644 index 000000000..aef2362f6 --- /dev/null +++ b/src/uu/shred/shred.md @@ -0,0 +1,47 @@ +# shred + + + +``` +shred [OPTION]... FILE... +``` + +Overwrite the specified FILE(s) repeatedly, in order to make it harder for even +very expensive hardware probing to recover the data. + +## After help + +Delete FILE(s) if `--remove` (`-u`) is specified. The default is not to remove +the files because it is common to operate on device files like /dev/hda, and +those files usually should not be removed. + +CAUTION: Note that shred relies on a very important assumption: that the file +system overwrites data in place. This is the traditional way to do things, but +many modern file system designs do not satisfy this assumption. The following +are examples of file systems on which shred is not effective, or is not +guaranteed to be effective in all file system modes: + + * log-structured or journal file systems, such as those supplied with + AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) + + * file systems that write redundant data and carry on even if some writes + fail, such as RAID-based file systems + + * file systems that make snapshots, such as Network Appliance's NFS server + + * file systems that cache in temporary locations, such as NFS + version 3 clients + + * compressed file systems + +In the case of ext3 file systems, the above disclaimer applies (and shred is +thus of limited effectiveness) only in `data=journal` mode, which journals file +data in addition to just metadata. In both the `data=ordered` (default) and +`data=writeback` modes, shred works as usual. Ext3 journal modes can be changed +by adding the `data=something` option to the mount options for a particular +file system in the `/etc/fstab` file, as documented in the mount man page (`man +mount`). + +In addition, file system backups and remote mirrors may contain copies of +the file that cannot be removed, and that will allow a shredded file to be +recovered later. diff --git a/src/uu/shred/src/shred.rs b/src/uu/shred/src/shred.rs index a0332e8ab..d0b9f5d93 100644 --- a/src/uu/shred/src/shred.rs +++ b/src/uu/shred/src/shred.rs @@ -6,7 +6,7 @@ // * For the full copyright and license information, please view the LICENSE // * file that was distributed with this source code. -// spell-checker:ignore (words) writeback wipesync +// spell-checker:ignore (words) wipesync use clap::{crate_version, Arg, ArgAction, Command}; use rand::prelude::SliceRandom; @@ -21,9 +21,8 @@ use std::os::unix::fs::PermissionsExt; use std::path::{Path, PathBuf}; use uucore::display::Quotable; use uucore::error::{FromIo, UResult, USimpleError, UUsageError}; -#[cfg(unix)] use uucore::libc::S_IWUSR; -use uucore::{format_usage, show, show_if_err, util_name}; +use uucore::{format_usage, help_about, help_section, help_usage, show, show_if_err, util_name}; // This block size seems to match GNU (2^16 = 65536) const BLOCK_SIZE: usize = 1 << 16; @@ -189,47 +188,9 @@ impl BytesWriter { } } -static ABOUT: &str = "Overwrite the specified FILE(s) repeatedly, in order to make it harder\n\ -for even very expensive hardware probing to recover the data. -"; -const USAGE: &str = "{} [OPTION]... FILE..."; - -static AFTER_HELP: &str = - "Delete FILE(s) if --remove (-u) is specified. The default is not to remove\n\ - the files because it is common to operate on device files like /dev/hda,\n\ - and those files usually should not be removed.\n\ - \n\ - 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, or is not guaranteed to be effective in all file system modes:\n\ - \n\ - * log-structured or journal file systems, such as those supplied with\n\ - AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)\n\ - \n\ - * file systems that write redundant data and carry on even if some writes\n\ - fail, such as RAID-based file systems\n\ - \n\ - * file systems that make snapshots, such as Network Appliance's NFS server\n\ - \n\ - * file systems that cache in temporary locations, such as NFS\n\ - version 3 clients\n\ - \n\ - * compressed file systems\n\ - \n\ - In the case of ext3 file systems, 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 journal 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\ - "; +const ABOUT: &str = help_about!("shred.md"); +const USAGE: &str = help_usage!("shred.md"); +const AFTER_HELP: &str = help_section!("after help", "shred.md"); pub mod options { pub const FORCE: &str = "force";