@command{shred} makes no attempt to detect or report this problem, just as
it makes no attempt to do anything about backups. However, since it is
more reliable to shred devices than files, @command{shred} by default does
-not truncate or remove the output file. This default is more suitable
-for devices, which typically cannot be truncated and should not be
+not deallocate or remove the output file. This default is more suitable
+for devices, which typically cannot be deallocated and should not be
removed.
Finally, consider the risk of backups and mirrors.
@opindex --remove=wipe
@opindex --remove=wipesync
@cindex removing files after shredding
-After shredding a file, truncate it (if possible) and then remove it.
+After shredding a file, deallocate it (if possible) and then remove it.
If a file has multiple links, only the named links will be removed.
Often the file name is less sensitive than the file data, in which case
the optional @var{how} parameter, supported with the long form option,
-s, --size=N shred this many bytes (suffixes like K, M, G accepted)\n\
"), DEFAULT_PASSES);
fputs (_("\
- -u truncate and remove file after overwriting\n\
+ -u deallocate and remove file after overwriting\n\
--remove[=HOW] like -u but give control on HOW to delete; See below\n\
-v, --verbose show progress\n\
-x, --exact do not round file sizes up to the next full block;\n\