summaryrefslogtreecommitdiff
path: root/tests/misc/shred-remove.sh
diff options
context:
space:
mode:
authorPádraig Brady <P@draigBrady.com>2013-11-07 17:00:56 +0000
committerPádraig Brady <P@draigBrady.com>2013-11-27 01:43:12 +0000
commit569b4edd18cddb5a8cc1f9549a7c1eed91b674f7 (patch)
tree00acb5a1a0da66ae42e6b61f2befd144c716f466 /tests/misc/shred-remove.sh
parentba6582e95ce2a041423e1ff34c93abe7b4702332 (diff)
downloadcoreutils-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/misc/shred-remove.sh')
-rwxr-xr-xtests/misc/shred-remove.sh19
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