A common annoyance in the free software world is an archive that leaves
several top-level files in the working directory after being extracted.
However, this is a special case of a more general annoyance, where files
can also be extracted to paths above the working directory. This adds an
option ca
A few comments:
It shouldn't be necessary to call malloc or to copy the
file name except in the special case where the first
top level is found.
Don't store string lengths in 'int'. Use size_t,
in case the string length exceeds INT_MAX.
Tar already prevents users from misusing "..", so
why does
On Sat, Sep 21, 2013 at 01:29:25 -0400, Nathan Stratton Treadway wrote:
> So I wonder if the "proper" fix at this point would be to switch
> everything to using the "virtual chdir" approach?
>
> (This seems a little strange, since it means changing the code path for
> --create, which is the branch
I notice in --appened mode, the --listed-incremental option is accepted
but seems to be completely ignored.
Would it make sense to add this combination of options to the list of
USAGE_ERRORs at the bottom of tar.c:decode_options() ?
Nathan
On Sat, Sep 21, 2013 at 17:09:09 -0400, Nathan Stratton Treadway wrote:
> I notice in --appened mode, the --listed-incremental option is accepted
> but seems to be completely ignored.
>
> Would it make sense to add this combination of options to the list of
> USAGE_ERRORs at the bottom of tar.c:de
On 21/09/13 08:28 AM, Paul Eggert wrote:
> A few comments:
>
> It shouldn't be necessary to call malloc or to copy the
> file name except in the special case where the first
> top level is found.
>
> Don't store string lengths in 'int'. Use size_t,
> in case the string length exceeds INT_MAX.
>
>
This adds the --one-top-level option to reject tarballs that do not
follow the practice of having everything in one directory. The only
option that appears to be in conflict is --absolute-names because the
code assumes that unsafe prefixes like ".." and leading slashes are
removed. Archives that fa
