[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
interrupting `shred -u's renaming: what should it do?
From: |
Jim Meyering |
Subject: |
interrupting `shred -u's renaming: what should it do? |
Date: |
Tue, 18 May 2004 17:53:30 +0200 |
Here's a little question:
If shred is interrupted while repeatedly renaming a file,
should it remove the file?
For those who haven't run `shred -u' with the --verbose,
here's some output demonstrating the renamings it performs
in an attempt to scribble on the original name in the directory entry:
$ : > private
$ shred -u --verbose --iterations=0 private
shred: private: removing
shred: private: renamed to 0000000
shred: 0000000: renamed to 000000
shred: 000000: renamed to 00000
shred: 00000: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: private: removed
My first reaction was that it's obvious:
Such an intermediate-named file should be removed.
But the goal of shred is to obfuscate and remove,
so a signal like SIGINT may indicate that someone
has decided they don't want to complete the task.
On the other hand, is it appropriate to leave behind
an obscurely-named file like one of the `0..00' ones above?
I'm leaning toward a compromise: have shred issue a warning
with the name of any file it leaves behind.
Comments welcome.
- interrupting `shred -u's renaming: what should it do?,
Jim Meyering <=