FW: glibc install problem caused by bug in zic (fwd)
Olson, Arthur David (NCI)
olsona at dc37a.nci.nih.gov
Tue Mar 5 16:09:17 UTC 2002
Peter Breitenlohner is not on the time zone mailing list; direct replies
From: Peter Breitenlohner [mailto:peb at 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.
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
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
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).
Peter Breitenlohner <peb at mppmu.mpg.de>
More information about the tz