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

[Bob Proulx]

Paul Jarc wrote:
> address@hidden (Bob Proulx) wrote:
> > Hmm...  Is there a way to rename atomically with a guarentee that it
> > will fail if the target exists?
> 
> No, but atomicity isn't the problem.  The problem is what to do if a
> new file has appeared with the original name.  Would we leave the
> operand file in place with its temporary name?  Then, since that case
> would exist anyway, is it still worthwhile to even try to move it back
> to the original name?

But I thought the purpose of the renames were to hide the fact that
the original name ever existed in the directory at all.  The name
itself might give information away if discovered.  But if a new file
appears by the same original name then there is no longer any need to
hide it with regards to the previous incarnation of the name.  At that
point the name can just be removed.

My comment pertained to my thought that if you could rename it and
fail if the name exists then that means in that case the file could be
removed.  But if the rename succeeded then things were restored as
much as possible to a sane state after an interrupt.

The atomic part comes into play here:

  process A                            process B
  ... interrupt...
  test if old name exists, no.
  ...delay...                          another process creates file
  rename file to old name              hey, what happened to my file?

So in order to make something like that work the trap handling
functionality of of rename-and-fail-if-target-exists needs to be an
atomic operation.

Bob