Re: Bug in canonicalize_path() - Mailing list pgsql-patches

From Tom Lane
Subject Re: Bug in canonicalize_path()
Date
Msg-id 23909.1123817961@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in canonicalize_path()  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Bug in canonicalize_path()  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I figured it would be best to leave it alone if we can't process it, but
> if you think it is more imporant to trim in cases like ../.., go ahead.

My recollection of this patch:

2004-08-09 16:20  tgl

    * src/: port/exec.c, port/path.c, bin/initdb/initdb.c:
    Path-mangling logic was failing to account for paths containing
    mentions of '.' or '..'.  Extend canonicalize_path() to trim off
    trailing occurrences of these things, and use it to fix up paths
    where needed (which I think is only after places where we trim the
    last path component, but maybe some others will turn up).  Fixes
    Josh's complaint that './initdb' does not work.

is that it's part of the API contract of canonicalize_path() that it
will not return something with trailing "." or "..".  It's not just
neatnik-ism to strip those, it's necessary to allow higher-level
path-mangling routines to reason about how to do what they need.
The entire concept of "trim the last directory" fails if you have
to account for "." or "..".

            regards, tom lane

pgsql-patches by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Re: remove BufferBlockPointers for speed and space
Next
From: Bruce Momjian
Date:
Subject: Re: Bug in canonicalize_path()