Re: [Bug-tar] segfault getting cwd with --listed-incremental

[Paul Eggert]

On 07/15/10 12:34, Sergey Poznyakoff wrote:
> I don't agree
> with the patch to normalize_filename_x.  This function must produce an
> absolute file name corresponding to the given relative one,
> *without* taking into account any symbolic links, so that the
> proposed patch simply breaks it.

OK, but aren't symlinks an argument for the patch, not an argument against it?
The patched code doesn't take symlinks into account either.  The previous
version rewrote A/B/../C as A/C, and surely this wasn't safe when B was
a symlink to some other directory.

Why must normalize_filename_x produce an absolute file name?  Is it because
a relative name is not robust when 'tar' does a chdir before using
the relative name?  If so, it would be better to fix the problem
by recording, with each normalized name, the directory that the name is
relative to (this would be the int result of chdir_arg).  Then, before
using the normalized name, tar could use chdir_do to make sure the name
is relative to the correct location.  That way, tar would not have to
invoke getcwd (except for unusual situations such as "." not being
readable).

What harm would be caused if we got rid of the 'caname' member of struct name,
and simply used the 'name' member?  Similarly for struct directory.
Would this harm be avoided if we replaced the 'caname' member with
an int member that records the directory that 'name' is relative to?
(Again, this directory would be recorded as the int returned from chdir_arg.)