RGBCube/uutils-coreutils
1
Fork 0
mirror of https://github.com/RGBCube/uutils-coreutils synced 2025-07-28 11:37:44 +00:00
Code Issues Activity

shred: move help strings to markdown files

Browse source
This commit is contained in:
Terts Diepraam 2023-03-10 20:49:26 +01:00
parent 0ff83388b9
commit 015de72931
2 changed files with 52 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

47
src/uu/shred/shred.md Normal file
View file

@ -0,0 +1,47 @@
# shred
<!-- spell-checker:ignore writeback -->
```
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.

49
src/uu/shred/src/shred.rs
View file

@ -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";