Peter Breitenlohner is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Peter Breitenlohner [mailto:peb@mppmu.mpg.de] Sent: Tuesday, March 05, 2002 11:07 AM To: Olson, Arthur David (NCI) Cc: List Time Zone (E-mail) Subject: RE: glibc install problem caused by bug in zic (fwd) On Tue, 5 Mar 2002, Olson, Arthur David (NCI) wrote:

...

+ /* + ** Proceed if there is a common prefix, + ** otherwise we can't create a reasonable symlink + ** (only happens when input and -d option are weird) + */

I can see how it's desirable to add a check that the fromfile exists when processing a "Link" line and resorting to a symbolic link. I don't (yet) see the need for a common prefix; I'd love it if someone could enlighten me.

Hi Arthur, Assume the command "zic -d foo filename" with an input "filename" containing Link this /bar/that All this is certainly foolish and doesn't happen when building glibc, but it could happen. The code at the start of the function "dolink(fromfile,tofile)" in zic.c:589ff first builds the paths fromname and toname by prepending "directory" (from the -d option or TZDIR) to fromfile and tofile it they are not already absolute path. Thus the program will try to create a link from "foo/this" to "/bar/that". It was this situation I wanted to catch by requiring a common prefix (at least "/" if fromname and toname are both absolute paths as they should be when zic is used properly). Maybe you were just misled by the wording "common prefix" which may indeed be not entirely apropriate. Note, however, that with my patch and its test for a common prefix an inputline Link sub/this sub/that will create a symlink "sub/this->that" and not "sub/this->../sub/that" as with the original code (always assuming that the hard link fails). regards Peter Breitenlohner <peb@mppmu.mpg.de>