From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, "wangsh(dot)fnst(at)fujitsu(dot)com" <wangsh(dot)fnst(at)fujitsu(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: drop tablespace failed when location contains .. on win32 |
Date: | 2021-09-09 12:30:29 |
Message-ID: | 5dc0799e-82ab-cc86-6dc6-915412f2585a@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/8/21 11:44 PM, Michael Paquier wrote:
> 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.
Maybe, although it's arguably a bug.
I think I would say that we should remove any "." or ".." element in the
path except at the beginning, and in the case of ".." also remove the
preceding element, unless someone can convince me that there's a problem
with that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-09-09 12:30:51 | Re: create table like: ACCESS METHOD |
Previous Message | Peter Eisentraut | 2021-09-09 12:11:50 | Re: Why does bootstrap and later initdb stages happen via client? |