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

Merge pull request #7925 from alexs-sh/shred-minor-updates

Browse source 
shred: minor improvements and tests
This commit is contained in:
Daniel Hofstetter 2025-05-21 17:11:29 +02:00 • committed by GitHub
commit 10b2a24a73
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 11 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -49,11 +49,11 @@ const NAME_CHARSET: &[u8] = b"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN
const PATTERN_LENGTH: usize = 3;
const PATTERN_BUFFER_SIZE: usize = BLOCK_SIZE + PATTERN_LENGTH - 1;
/// Optimal block size for the filesystem. This constant is used for data size alignment,
/// similar to the behavior of GNU shred. Usually, optimal block size is a 4K block, which is why
/// Optimal block size for the filesystem. This constant is used for data size alignment, similar
/// to the behavior of GNU shred. Usually, optimal block size is a 4K block (2^12), which is why
/// it's defined as a constant. However, it's possible to get the actual size at runtime using, for
/// example, `std::os::unix::fs::MetadataExt::blksize()`.
const OPTIMAL_IO_BLOCK_SIZE: usize = 4096;
const OPTIMAL_IO_BLOCK_SIZE: usize = 1 << 12;
/// Patterns that appear in order for the passes
///
@ -514,12 +514,17 @@ fn wipe_file(
}
fn split_on_blocks(file_size: u64, exact: bool) -> (u64, u64) {
// OPTIMAL_IO_BLOCK_SIZE must not exceed BLOCK_SIZE. Violating this may cause overflows due
// to alignment or performance issues.This kind of misconfiguration is
// highly unlikely but would indicate a serious error.
const _: () = assert!(OPTIMAL_IO_BLOCK_SIZE <= BLOCK_SIZE);
let file_size = if exact {
file_size
} else {
// The main idea here is to align the file size to the OPTIMAL_IO_BLOCK_SIZE, and then split it into
// BLOCK_SIZE + remaining bytes. Since the input data is already aligned to N * OPTIMAL_IO_BLOCK_SIZE,
// the output file size will also be aligned and correct.
// The main idea here is to align the file size to the OPTIMAL_IO_BLOCK_SIZE, and then
// split it into BLOCK_SIZE + remaining bytes. Since the input data is already aligned to N
// * OPTIMAL_IO_BLOCK_SIZE, the output file size will also be aligned and correct.
file_size.div_ceil(OPTIMAL_IO_BLOCK_SIZE as u64) * OPTIMAL_IO_BLOCK_SIZE as u64
};
(file_size / BLOCK_SIZE as u64, file_size % BLOCK_SIZE as u64)