From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | koichi(dot)dbms(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
Date: | 2024-12-06 06:42:48 |
Message-ID: | 20241206.154248.1191531539866262856.ishii@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> I don't believe the theory that the fault lies there. If the flex
> rules were taking the backslash-embedded-in-a-shift-JIS-character
> as a backslash, they would think it is the start of a new backslash
> command, with the result being that the filename argument gets
> truncated there. That doesn't match the reported symptoms: we
> see more of the filename than that echoed back in the error message.
> So I think the filename is getting through that part just fine,
> and then we're messing it up in canonicalize_path or adjacent
> processing.
I have looked into canonicalize_path() and found this:
#ifdef WIN32
/*
* The Windows command processor will accept suitably quoted paths with
* forward slashes, but barfs badly with mixed forward and back slashes.
*/
for (p = path; *p; p++)
{
if (*p == '\\')
*p = '/';
}
Here "path" is the filename encoded in Shift-JIS I think. It seems
canonicalize_path() unconditionaly replaces a backslash with a slash.
For me this seems to break any Shift-JIS KANJI characters that a
backslash in the second byte.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | KALLIOPI DIMOKA | 2024-12-06 08:17:07 | Install postgres 14 on SLES 15 SP1 |
Previous Message | Tatsuo Ishii | 2024-12-06 06:29:01 | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |