bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: interrupting `shred -u's renaming: what should it do?


From: Bob Proulx
Subject: Re: interrupting `shred -u's renaming: what should it do?
Date: Wed, 19 May 2004 09:28:51 -0600
User-agent: Mutt/1.3.28i

Jim Meyering wrote:
> Here's a little question:
> 
>   If shred is interrupted while repeatedly renaming a file,
>   should it remove the file?

Since shred was interrupted, was unable to shred the file, I think it
should return the file to the previous name.

> 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

  ...interrupt...
  trap it and rename "00000" back to "private"  # suggestion

The reasoning for me is that if shred was walking many files the files
that were removed would be processed completely.  The files it had not
gotten to at all would be untouched.  The file it was processing at
the moment of interruption should be pushed back in the queue to be
processed later in the same way as if it had never touched it.

Of course at this point the file contents are already shred'd, right?
But to the user who interrupted the command I think that is expected.

Note that I did not look at the code so I have no idea if my
suggestion is practical.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]