Date: Fri, 06 Dec 2024 15:42:48 +0900 (JST)
Message-Id: <20241206.154248.1191531539866262856.ishii@postgresql.org>
To: tgl@sss.pgh.pa.us
Cc: koichi.dbms@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18735: Specific multibyte character in psql file path
 command parameter for Windows
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: <2751825.1733464455@sss.pgh.pa.us>
References: <20241206.142130.1661155698933375612.ishii@postgresql.org>
	<CABEZHFurokPoY+Vs0zhSf7J5ahZV1p7naOPiH5_3C-ubPdDWgA@mail.gmail.com>
	<2751825.1733464455@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20241206.154248.1191531539866262856.ishii%40postgresql.org>
Precedence: bulk

> 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