FW: GNU tar 1.13.17 --overwrite works "wrong"

[Patterson, Ross]

Sorry, stupid MS shortcut keys sent that one before it's time.  What I meant to 
say was ...

> The NEWS file for GNU tar 1.13.17 says:
> 
>       version 1.13.16 - Paul Eggert, 1999-12-13.
> 
>       * By default, tar now refuses to overwrite existing files when
>         extracting files from an archive; instead, it removes them before
>         extracting.  There is one exception: existing nonempty directories
>         are not removed, nor are their ownerships or permissions extracted.
>         This fixes some longstanding security problems.
> 
>         The new --overwrite option enables the old default behavior.
> 
>       ...
> 
> The second paragraph implies that "tar -x --overwrite" will behave exactly 
> the same in 1.13.17 as "tar -x" in levels up to 1.13.15.  I've got a case 
> where it doesn't, and it's a problem I can't seem to resolve.  Specifically, 
> my company sells a product that includes a tar archive as the distribution 
> vehicle.  The archive contains several independently-selectable components, 
> organized in a directory tree much as you'd expect - directory "a" contains 
> the "a" component files, "b" contains "b", etc.  When we install, we want to 
> install all  the files for the components that the user chooses, and all in 
> the same directory.  Just to complicate matters, there are some files that 
> are present in more than one component (identical), and we want tar to 
> silently 
> replace one copy with another (because we KNOW that they're identical).  The 
> following works on releases prior to 1.13.16:
> 
>       mkdir /install_target_dir
>       ln -s /install_target_dir /install_target_dir/a
>       ln -s /install_target_dir /install_target_dir/b
>       ... more links, one for each component ...
>       tar xzfp dist.tar.Z a b ... more components, as chosen by the user ...
>       rm -f /install_target_dir/a
>       rm -f /install_target_dir/b
>       ... more cleanup ...
> 
> The effect we're looking for is to have all the files from the chosen 
> components installed into /install_target_dir, and tar used to follow the 
> symlinks and "make it so".  This was even deliberate behavior - "info tar" 
> for 
> 1.12 says:
> 
>       Options to Prevent Overwriting Files
>       ....................................
>          Normally, `tar' writes extracted files into the file system without
>       regard to the files already on the system; i.e., files with the same
>       names as archive members are overwritten when the archive is extracted.
>       If the name of a corresponding file is a symbolic link, the file
>       pointed to by the symbolic link will be overwritten instead of the
>       symbolic link itself (if this is possible). ...
> 
> GNU tar 1.13.17 does exactly what we don't want - it replaces the 
> carefully-built 
> symlinks with directories, and all the component files wind up in these new 
> directories.  The 1.13.16 --overwrite option appears to be intended to 
> restore 
> the old behavior, but instead seems to have no effect.  The --keep-old-files 
makes tar follow the symlinks, but also makes it generate RC=2, indicating an 
error to the surrounding script.

So, what's a poor boy to do?  I can't ask for a tar patch, I've got to be able 
to install on systems already in the field today.  And the --overwrite option 
doesn't seem to do what it was intended to do - revert to prior behavior.  Any 
suggestions?

Ross Patterson
Computer Associates