[Bug-tar] unpacking archives where file.name may be a different type

[Neal P. Murphy]

[In general, I use 'file' and 'dir' interchangeably here to mean
'something that tar has archived or restored'.]

Re:
http://lists.gnu.org/archive/html/bug-tar/2005-09/msg00026.html

I've been bitten a number of times by tar 1.28 silently replacing
symlinks with dirs when extracting archives. I believe this is wrong.

I do not intend to create a firestorm. Or be negative. Considering that
tar originally only dealt with files and dirs (I remember when it
wouldn't handle device nodes), it's had a lot of functionality added
over the years. I do wonder if tar does the right thing(s) when
replacing existing files and dirs. Were all the implications considered?

I understand that it can be a security problem when the contents of an
archived dir are restored through a symlink. But silently replacing the
symlink with a dir can be just as disruptive and dangerous, primarily
because the user receives no notice that the symlink has been replaced.
It would be just as disruptive and potentially as dangerous to delete
a dir and create a symlink in its place.

In the general case, tar (and all of its relatives) should vocally
(verbally) refuse to restore anything that is not the same type as the
existing file of the same name. For example, tar should not replace a
regular file with a socket, a symlink with a file, or a socket with a
device node; it should exit with a non-zero status when it has so
refused. I haven't decided if it should fail immediately or continue to
unpack what it can.

I know there are some options that can control this behaviour, but they
aren't necessarily written very well. Example:
----
     -h, --dereference
           follow symlinks; archive and dump the files they point to
----
This tells me that symlinks will be followed when the archive is
created. The option doesn't seem to apply when unpacking an archive.
Would it help to have an option, or a 'class' of options, that allow the
user to specify which file type may overwrite another type?

In summary,
  - tar should not silently overwrite files of a different type unless
    an option has been specified that allows tar to perform that action;
  - tar should exit non-zero when it has refused to overwrite at least
    one file of a different type;
  - tar should display a warning or error each time it refuses to
    overwrite a file of a different type.
That is, don't silently take unexpected action, and give the user every
chance to detect that tar has refused to do something a little strange.

Neal