From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | wangsh(dot)fnst(at)fujitsu(dot)com, andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: drop tablespace failed when location contains .. on win32 |
Date: | 2021-09-09 04:34:14 |
Message-ID: | 20210909.133414.2254130398190080456.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 9 Sep 2021 12:44:45 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Thu, Sep 09, 2021 at 02:35:52AM +0000, wangsh(dot)fnst(at)fujitsu(dot)com wrote:
> > Do you mean changing the action of canonicalize_path(), like remove all the (..) ?
> >
> > I'm willing to fix this problem.
>
> Looking at canonicalize_path(), we have already some logic around
> pending_strips to remove paths when we find a "/.." in the path, so
> that's a matter of adjusting this area to trim properly the previous
> directory.
>
> On *nix platforms, we don't apply this much caution either, say a
> simple /tmp/path/../path/ results in this same path used in the link
> from pg_tblspc. But we are speaking about Windows here, and junction
> points.
>
> Based on the lack of complains over the years, that does not seem
> really worth backpatching. Just my 2c on this point.
Reading the first complaint, I remember I proposed that as a part of a
larger patch.
https://www.postgresql.org/message-id/20190425.170855.39056106.horiguchi.kyotaro%40lab.ntt.co.jp
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-09-09 04:59:31 | Re: Schema variables - new implementation for Postgres 15 |
Previous Message | Michael Paquier | 2021-09-09 04:28:54 | Re: strange case of "if ((a & b))" |