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.)
