diff options
author | Pádraig Brady <P@draigBrady.com> | 2013-11-07 17:00:56 +0000 |
---|---|---|
committer | Pádraig Brady <P@draigBrady.com> | 2013-11-27 01:43:12 +0000 |
commit | 569b4edd18cddb5a8cc1f9549a7c1eed91b674f7 (patch) | |
tree | 00acb5a1a0da66ae42e6b61f2befd144c716f466 /tests | |
parent | ba6582e95ce2a041423e1ff34c93abe7b4702332 (diff) | |
download | coreutils-569b4edd18cddb5a8cc1f9549a7c1eed91b674f7.tar.xz |
shred: provide --remove methods to avoid excessive syncing
A sync operation is very often expensive. For illustration
I timed the following python script which indicated that
each ext4 dir sync was taking about 2ms and 12ms, on an
SSD and traditional disk respectively.
import os
d=os.open(".", os.O_DIRECTORY|os.O_RDONLY)
for i in range(1000):
os.fdatasync(d)
So syncing for each character for each file can result
in significant delays. Often this overhead is redundant,
as only the data is sensitive and not the file name.
Even if the names are sensitive, your file system may
employ synchronous metadata updates, which also makes
explicit syncing redundant.
* tests/misc/shred-remove.sh: Ensure all the new parameters
actually unlink the file.
* doc/coreutils.texi (shred invocation): Describe the new
parameters to the --remove option.
* src/shred.c (Usage): Likewise.
(main): Parse the new options.
(wipename): Inspect the new enum to see which of
the now optional tasks to perform.
* NEWS: Mention the new feature.
* THANKS.in: Add reporter Joseph D. Wagner
Diffstat (limited to 'tests')
-rwxr-xr-x | tests/misc/shred-remove.sh | 19 |
1 files changed, 15 insertions, 4 deletions
diff --git a/tests/misc/shred-remove.sh b/tests/misc/shred-remove.sh index 891dc2d21..5ccfbe295 100755 --- a/tests/misc/shred-remove.sh +++ b/tests/misc/shred-remove.sh @@ -1,5 +1,5 @@ #!/bin/sh -# Exercise a bug that was fixed in shred-4.0l +# Exercise shred --remove # Copyright (C) 1999-2013 Free Software Foundation, Inc. @@ -21,16 +21,27 @@ print_ver_ shred skip_if_root_ # The length of the basename is what matters. -# In this case, shred would try to rename the file 256^10 times +# In this case, shred-4.0l would try to rename the file 256^10 times # before terminating. file=0123456789 touch $file || framework_failure_ chmod u-w $file || framework_failure_ - # This would take so long that it appears to infloop # when using version from fileutils-4.0k. # When the command completes, expect it to fail. -shred -u $file > /dev/null 2>&1 && fail=1 || : +shred -u $file > /dev/null 2>&1 && fail=1 +rm -f $file || framework_failure_ + +# Ensure all --remove methods at least unlink the file +for mode in '' '=unlink' '=wipe' '=wipesync'; do + touch $file || framework_failure_ + shred -n0 --remove"$mode" $file || fail=1 + test -e $file && fail=1 +done + +# Ensure incorrect params are diagnosed +touch $file || framework_failure_ +shred -n0 --remove=none $file 2>/dev/null && fail=1 Exit $fail |