From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 00:53:27 2013 Received: (at submit) by debbugs.gnu.org; 26 Jan 2013 05:53:27 +0000 Received: from localhost ([127.0.0.1]:49859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tyyhj-0006UO-A2 for submit@debbugs.gnu.org; Sat, 26 Jan 2013 00:53:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57947) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tyyhh-0006UE-AD for submit@debbugs.gnu.org; Sat, 26 Jan 2013 00:53:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TyyhS-0004HW-6W for submit@debbugs.gnu.org; Sat, 26 Jan 2013 00:53:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:59413) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyyhS-0004HS-3G for submit@debbugs.gnu.org; Sat, 26 Jan 2013 00:53:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyyhP-0007jt-A3 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 00:53:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TyyhM-0004GA-Ny for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 00:53:07 -0500 Received: from mail-da0-f42.google.com ([209.85.210.42]:59289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyyhM-0004Fy-H2 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 00:53:04 -0500 Received: by mail-da0-f42.google.com with SMTP id z17so488192dal.1 for ; Fri, 25 Jan 2013 21:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-mailer:message-id; bh=cV0980aavbB0J+73m5v+eI9Bqm7C4ZN7opMYOF9KHW8=; b=SkZTCQ+fItS8T3EaS1NFyjSUGJXLrRuvq5vlR0HUgf/ZWP/Q8fetgdDj2qEtouyfc3 gepyzjUiAjtCZO/C/il0/aRdA/Y6F5lNTHPUY2NK04Is//q3LUj0RSPUSwrliYqVZp8/ PSkfN6x96v4Toe0J/86Dtc7qFkxNU/nBxH42GW8svGjwth0MVSUTa8DKDvHcNDwlUG2+ 2t5+jeIEx3NFUjZ99Mw0I98rNMGlbY6sWrtrvCfgI0QgnHR4uiwfWLfSyihGmQjRC0dD cZHUiA2hk3DEG5Z85AGSLJxs2riABWo6tEuiNGoYBEoHu8cA4MdclCmGSbFxQNMDlOR/ hUkQ== X-Received: by 10.66.76.8 with SMTP id g8mr19063718paw.40.1359179582846; Fri, 25 Jan 2013 21:53:02 -0800 (PST) Received: from gmail.com (115x125x38x6.ap115.ftth.ucom.ne.jp. [115.125.38.6]) by mx.google.com with ESMTPS id x2sm2264802paw.8.2013.01.25.21.52.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Jan 2013 21:53:01 -0800 (PST) From: Shigeru Fukaya To: bug-gnu-emacs@gnu.org Subject: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Date: Sat, 26 Jan 2013 14:52:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.00 (WinNT,601) Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Hi, `file-attributes' returns nil as stat info for a file, its name ending with a character whose second byte is 0x5c. It is because IS_DIRECTORY_SEP is wrongly used. IS_DIRECTORY_SEP only works when its argument is surely on a start byte of dbcs characters. I find incorrect usage, at least in some functions of `w32.c'. (readdir, stat_worker, read_unc_volume) I show, as a silly sample, of easy fix. #define IS_AT_DIRECTORY_SEP(p,i) \ (p[i] == '/' || (p[i] == '\\' && _mbsbtype(p,i) == _MBC_SINGLE)) and, IS_DIRECTORY_SEP(p[i]) to IS_AT_DIRECTORY_SEP(p, i) Regards, Shigeru From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 06:09:19 2013 Received: (at submit) by debbugs.gnu.org; 26 Jan 2013 11:09:19 +0000 Received: from localhost ([127.0.0.1]:50035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz3dO-0005Zj-FB for submit@debbugs.gnu.org; Sat, 26 Jan 2013 06:09:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51794) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz3dL-0005ZV-QV for submit@debbugs.gnu.org; Sat, 26 Jan 2013 06:09:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tz3d6-0001TC-J0 for submit@debbugs.gnu.org; Sat, 26 Jan 2013 06:09:02 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz3d6-0001T8-Ft for submit@debbugs.gnu.org; Sat, 26 Jan 2013 06:09:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz3d4-0008Hu-9l for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 06:09:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tz3d3-0001SI-6u for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 06:08:58 -0500 Received: from smtp208.alice.it ([82.57.200.104]:52662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tz3d2-0001Rz-SS for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 06:08:57 -0500 Received: from fmsmemgm.homelinux.net (82.107.57.105) by smtp208.alice.it (8.6.060.12) id 50FF9F1D00A7D1BD for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 12:08:55 +0100 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 7B17BAE3F4; Sat, 26 Jan 2013 06:08:53 -0500 (EST) Resent-Message-ID: Resent-To: bug-gnu-emacs@gnu.org Resent-From: Stefan Monnier Resent-Date: Sat, 26 Jan 2013 06:08:53 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 8FDFEAE2BE; Sat, 26 Jan 2013 05:26:04 -0500 (EST) From: Stefan Monnier To: Shigeru Fukaya Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Message-ID: References: Date: Sat, 26 Jan 2013 05:26:04 -0500 In-Reply-To: (Shigeru Fukaya's message of "Sat, 26 Jan 2013 14:52:59 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: submit Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.8 (----) > It is because IS_DIRECTORY_SEP is wrongly used. > IS_DIRECTORY_SEP only works when its argument is surely on a start > byte of dbcs characters. If the file name is properly decoded (i.e. in its multibyte form), there can't be a 0x5c byte other than at the beginning of a char. So this bug can only happens if you pass a unibyte filename. IOW the bug is probably in the caller rather than in the file-attributes function. Please show us the actual situation where this happens, since file names are normally always multibyte. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 06:17:33 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 11:17:33 +0000 Received: from localhost ([127.0.0.1]:50068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz3lN-0005nT-9l for submit@debbugs.gnu.org; Sat, 26 Jan 2013 06:17:33 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:55299) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz3lK-0005nL-TX for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 06:17:32 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MH800100CJAF100@a-mtaout20.012.net.il> for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 13:16:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH8001MPCNS6K50@a-mtaout20.012.net.il>; Sat, 26 Jan 2013 13:16:40 +0200 (IST) Date: Sat, 26 Jan 2013 13:16:50 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83obgcjisd.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Date: Sat, 26 Jan 2013 05:26:04 -0500 > Cc: 13553@debbugs.gnu.org > > > It is because IS_DIRECTORY_SEP is wrongly used. > > IS_DIRECTORY_SEP only works when its argument is surely on a start > > byte of dbcs characters. > > If the file name is properly decoded (i.e. in its multibyte form), there > can't be a 0x5c byte other than at the beginning of a char. > > So this bug can only happens if you pass a unibyte filename. IOW the > bug is probably in the caller rather than in the file-attributes function. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4944] X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org, shigeru.fukaya@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Date: Sat, 26 Jan 2013 05:26:04 -0500 > Cc: 13553@debbugs.gnu.org > > > It is because IS_DIRECTORY_SEP is wrongly used. > > IS_DIRECTORY_SEP only works when its argument is surely on a start > > byte of dbcs characters. > > If the file name is properly decoded (i.e. in its multibyte form), there > can't be a 0x5c byte other than at the beginning of a char. > > So this bug can only happens if you pass a unibyte filename. IOW the > bug is probably in the caller rather than in the file-attributes function. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4112] > From: Stefan Monnier > Date: Sat, 26 Jan 2013 05:26:04 -0500 > Cc: 13553@debbugs.gnu.org > > > It is because IS_DIRECTORY_SEP is wrongly used. > > IS_DIRECTORY_SEP only works when its argument is surely on a start > > byte of dbcs characters. > > If the file name is properly decoded (i.e. in its multibyte form), there > can't be a 0x5c byte other than at the beginning of a char. > > So this bug can only happens if you pass a unibyte filename. IOW the > bug is probably in the caller rather than in the file-attributes function. No, it's not in the caller. It's in w32.c, whose functions almost always manipulate encoded file names (because they shadow system APIs). > Please show us the actual situation where this happens, since file names > are normally always multibyte. You call file-attributes, which encodes the file name and passes it to 'lstat'. The implementation of 'lstat' in w32.c then looks at the last byte of the encoded file name to see if there's a slash or backslash there. Boom! I will fix that. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 07:57:02 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 12:57:02 +0000 Received: from localhost ([127.0.0.1]:50161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz5Jd-0000ar-ED for submit@debbugs.gnu.org; Sat, 26 Jan 2013 07:57:02 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:44683) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz5Ja-0000af-64 for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 07:57:00 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MH800200H1LX100@a-mtaout22.012.net.il> for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 14:56:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH800215HACWD30@a-mtaout22.012.net.il>; Sat, 26 Jan 2013 14:56:37 +0200 (IST) Date: Sat, 26 Jan 2013 14:56:46 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Shigeru Fukaya Message-id: <83libgje5t.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Shigeru Fukaya > Date: Sat, 26 Jan 2013 14:52:59 +0900 > > `file-attributes' returns nil as stat info for a file, its name ending > with a character whose second byte is 0x5c. > > It is because IS_DIRECTORY_SEP is wrongly used. > IS_DIRECTORY_SEP only works when its argument is surely on a start > byte of dbcs characters. > I find incorrect usage, at least in some functions of `w32.c'. > (readdir, stat_worker, read_unc_volume) [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4961] X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Shigeru Fukaya > Date: Sat, 26 Jan 2013 14:52:59 +0900 > > `file-attributes' returns nil as stat info for a file, its name ending > with a character whose second byte is 0x5c. > > It is because IS_DIRECTORY_SEP is wrongly used. > IS_DIRECTORY_SEP only works when its argument is surely on a start > byte of dbcs characters. > I find incorrect usage, at least in some functions of `w32.c'. > (readdir, stat_worker, read_unc_volume) Thanks. I fixed w32.c functions that use IS_DIRECTORY_SEP in revision 111200 on the emacs-24 branch. As I cannot easily test DBCS file-name encodings on my system, please test the fixed version and see if the problem indeed goes away. The patch relative to emacs-24 branch is below, for your convenience. After looking at the code which I fixed, I'm afraid I don't understand why file-attributes returned nil in your case. The code that uses IS_DIRECTORY_SEP there is only a fallback, for when the GetFileInformationByHandle API fails for some reason. You don't say what version of Windows you are using, but I won't expect that fallback code be executed for any reasonably recent Windows version. So could you please trace through the code that file-attributes calls, and see which use of IS_DIRECTORY_SEP caused the problem? I'm afraid that it's not in w32.c at all, but elsewhere. === modified file 'src/w32.c' --- src/w32.c 2013-01-25 14:47:37 +0000 +++ src/w32.c 2013-01-26 12:49:34 +0000 @@ -1503,12 +1503,17 @@ parse_root (char * name, char ** pPath) else if (IS_DIRECTORY_SEP (name[0]) && IS_DIRECTORY_SEP (name[1])) { int slashes = 2; + int dbcs_p = max_filename_mbslen () > 1; + name += 2; do { if (IS_DIRECTORY_SEP (*name) && --slashes == 0) break; - name++; + if (dbcs_p) + name = CharNextExA (file_name_codepage, name, 0); + else + name++; } while ( *name ); if (IS_DIRECTORY_SEP (name[0])) @@ -2369,12 +2374,23 @@ get_volume_info (const char * name, cons { char *str = temp; int slashes = 4; + int dbcs_p = max_filename_mbslen () > 1; + rootname = temp; do { if (IS_DIRECTORY_SEP (*name) && --slashes == 0) break; - *str++ = *name++; + if (!dbcs_p) + *str++ = *name++; + else + { + const char *p = name; + + name = CharNextExA (file_name_codepage, name, 0); + memcpy (str, p, name - p); + str += name - p; + } } while ( *name ); @@ -2610,11 +2626,23 @@ readdir (DIR *dirp) { char filename[MAXNAMLEN + 3]; int ln; + int dbcs_p = max_filename_mbslen () > 1; strcpy (filename, dir_pathname); ln = strlen (filename) - 1; - if (!IS_DIRECTORY_SEP (filename[ln])) - strcat (filename, "\\"); + if (!dbcs_p) + { + if (!IS_DIRECTORY_SEP (filename[ln])) + strcat (filename, "\\"); + } + else + { + char *end = filename + ln + 1; + char *last_char = CharPrevExA (file_name_codepage, filename, end, 0); + + if (!IS_DIRECTORY_SEP (*last_char)) + strcat (filename, "\\"); + } strcat (filename, "*"); /* Note: No need to resolve symlinks in FILENAME, because @@ -2719,6 +2747,7 @@ read_unc_volume (HANDLE henum, char *rea DWORD bufsize = 512; char *buffer; char *ptr; + int dbcs_p = max_filename_mbslen () > 1; count = 1; buffer = alloca (bufsize); @@ -2729,7 +2758,13 @@ read_unc_volume (HANDLE henum, char *rea /* WNetEnumResource returns \\resource\share...skip forward to "share". */ ptr = ((LPNETRESOURCE) buffer)->lpRemoteName; ptr += 2; - while (*ptr && !IS_DIRECTORY_SEP (*ptr)) ptr++; + if (!dbcs_p) + while (*ptr && !IS_DIRECTORY_SEP (*ptr)) ptr++; + else + { + while (*ptr && !IS_DIRECTORY_SEP (*ptr)) + ptr = CharNextExA (file_name_codepage, ptr, 0); + } ptr++; strncpy (readbuf, ptr, size); @@ -2766,9 +2801,11 @@ logon_network_drive (const char *path) { NETRESOURCE resource; char share[MAX_PATH]; - int i, n_slashes; + int n_slashes; char drive[4]; UINT drvtype; + char *p; + int dbcs_p; if (IS_DIRECTORY_SEP (path[0]) && IS_DIRECTORY_SEP (path[1])) drvtype = DRIVE_REMOTE; @@ -2790,13 +2827,18 @@ logon_network_drive (const char *path) n_slashes = 2; strncpy (share, path, MAX_PATH); /* Truncate to just server and share name. */ - for (i = 2; i < MAX_PATH; i++) + dbcs_p = max_filename_mbslen () > 1; + for (p = share + 2; *p && p < share + MAX_PATH; ) { - if (IS_DIRECTORY_SEP (share[i]) && ++n_slashes > 3) + if (IS_DIRECTORY_SEP (*p) && ++n_slashes > 3) { - share[i] = '\0'; + *p = '\0'; break; } + if (dbcs_p) + p = CharNextExA (file_name_codepage, p, 0); + else + p++; } resource.dwType = RESOURCETYPE_DISK; @@ -3557,6 +3599,7 @@ stat_worker (const char * path, struct s DWORD access_rights = 0; DWORD fattrs = 0, serialnum = 0, fs_high = 0, fs_low = 0, nlinks = 1; FILETIME ctime, atime, wtime; + int dbcs_p; if (path == NULL || buf == NULL) { @@ -3751,6 +3794,7 @@ stat_worker (const char * path, struct s did not ask for extra precision, resolving symlinks will fly in the face of that request, since the user then wants the lightweight version of the code. */ + dbcs_p = max_filename_mbslen () > 1; rootdir = (path >= save_name + len - 1 && (IS_DIRECTORY_SEP (*path) || *path == 0)); @@ -3778,8 +3822,19 @@ stat_worker (const char * path, struct s } else if (rootdir) { - if (!IS_DIRECTORY_SEP (name[len-1])) - strcat (name, "\\"); + if (!dbcs_p) + { + if (!IS_DIRECTORY_SEP (name[len-1])) + strcat (name, "\\"); + } + else + { + char *end = name + len; + char *n = CharPrevExA (file_name_codepage, name, end, 0); + + if (!IS_DIRECTORY_SEP (*n)) + strcat (name, "\\"); + } if (GetDriveType (name) < 2) { errno = ENOENT; @@ -3791,15 +3846,37 @@ stat_worker (const char * path, struct s } else { - if (IS_DIRECTORY_SEP (name[len-1])) - name[len - 1] = 0; + if (!dbcs_p) + { + if (IS_DIRECTORY_SEP (name[len-1])) + name[len - 1] = 0; + } + else + { + char *end = name + len; + char *n = CharPrevExA (file_name_codepage, name, end, 0); + + if (IS_DIRECTORY_SEP (*n)) + *n = 0; + } /* (This is hacky, but helps when doing file completions on network drives.) Optimize by using information available from active readdir if possible. */ len = strlen (dir_pathname); - if (IS_DIRECTORY_SEP (dir_pathname[len-1])) - len--; + if (!dbcs_p) + { + if (IS_DIRECTORY_SEP (dir_pathname[len-1])) + len--; + } + else + { + char *end = dir_pathname + len; + char *n = CharPrevExA (file_name_codepage, dir_pathname, end, 0); + + if (IS_DIRECTORY_SEP (*n)) + len--; + } if (dir_find_handle != INVALID_HANDLE_VALUE && !(is_a_symlink && follow_symlinks) && strnicmp (save_name, dir_pathname, len) == 0 @@ -4060,6 +4137,7 @@ symlink (char const *filename, char cons char linkfn[MAX_PATH], *tgtfn; DWORD flags = 0; int dir_access, filename_ends_in_slash; + int dbcs_p; /* Diagnostics follows Posix as much as possible. */ if (filename == NULL || linkname == NULL) @@ -4085,6 +4163,8 @@ symlink (char const *filename, char cons return -1; } + dbcs_p = max_filename_mbslen () > 1; + /* Note: since empty FILENAME was already rejected, we can safely refer to FILENAME[1]. */ if (!(IS_DIRECTORY_SEP (filename[0]) || IS_DEVICE_SEP (filename[1]))) @@ -4099,8 +4179,21 @@ symlink (char const *filename, char cons char tem[MAX_PATH]; char *p = linkfn + strlen (linkfn); - while (p > linkfn && !IS_ANY_SEP (p[-1])) - p--; + if (!dbcs_p) + { + while (p > linkfn && !IS_ANY_SEP (p[-1])) + p--; + } + else + { + char *p1 = CharPrevExA (file_name_codepage, linkfn, p, 0); + + while (p > linkfn && !IS_ANY_SEP (*p1)) + { + p = p1; + p1 = CharPrevExA (file_name_codepage, linkfn, p1, 0); + } + } if (p > linkfn) strncpy (tem, linkfn, p - linkfn); tem[p - linkfn] = '\0'; @@ -4115,7 +4208,15 @@ symlink (char const *filename, char cons exist, but ends in a slash, we create a symlink to directory. If FILENAME exists and is a directory, we always create a symlink to directory. */ - filename_ends_in_slash = IS_DIRECTORY_SEP (filename[strlen (filename) - 1]); + if (!dbcs_p) + filename_ends_in_slash = IS_DIRECTORY_SEP (filename[strlen (filename) - 1]); + else + { + const char *end = filename + strlen (filename); + const char *n = CharPrevExA (file_name_codepage, filename, end, 0); + + filename_ends_in_slash = IS_DIRECTORY_SEP (*n); + } if (dir_access == 0 || filename_ends_in_slash) flags = SYMBOLIC_LINK_FLAG_DIRECTORY; @@ -4440,6 +4541,7 @@ chase_symlinks (const char *file) char link[MAX_PATH]; ssize_t res, link_len; int loop_count = 0; + int dbcs_p; if (is_windows_9x () == TRUE || !is_symlink (file)) return (char *)file; @@ -4447,13 +4549,27 @@ chase_symlinks (const char *file) if ((link_len = GetFullPathName (file, MAX_PATH, link, NULL)) == 0) return (char *)file; + dbcs_p = max_filename_mbslen () > 1; target[0] = '\0'; do { /* Remove trailing slashes, as we want to resolve the last non-trivial part of the link name. */ - while (link_len > 3 && IS_DIRECTORY_SEP (link[link_len-1])) - link[link_len--] = '\0'; + if (!dbcs_p) + { + while (link_len > 3 && IS_DIRECTORY_SEP (link[link_len-1])) + link[link_len--] = '\0'; + } + else if (link_len > 3) + { + char *n = CharPrevExA (file_name_codepage, link, link + link_len, 0); + + while (n >= link + 2 && IS_DIRECTORY_SEP (*n)) + { + n[1] = '\0'; + n = CharPrevExA (file_name_codepage, link, n, 0); + } + } res = readlink (link, target, MAX_PATH); if (res > 0) @@ -4466,8 +4582,21 @@ chase_symlinks (const char *file) the symlink, then copy the result back to target. */ char *p = link + link_len; - while (p > link && !IS_ANY_SEP (p[-1])) - p--; + if (!dbcs_p) + { + while (p > link && !IS_ANY_SEP (p[-1])) + p--; + } + else + { + char *p1 = CharPrevExA (file_name_codepage, link, p, 0); + + while (p > link && !IS_ANY_SEP (*p1)) + { + p = p1; + p1 = CharPrevExA (file_name_codepage, link, p1, 0); + } + } strcpy (p, target); strcpy (target, link); } From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 08:23:36 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 13:23:36 +0000 Received: from localhost ([127.0.0.1]:50191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz5jL-0001Dv-Ti for submit@debbugs.gnu.org; Sat, 26 Jan 2013 08:23:36 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:49154) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz5jJ-0001Dm-84 for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 08:23:34 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MH800200IB5H000@a-mtaout20.012.net.il> for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 15:22:53 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH8001N6II4VKB0@a-mtaout20.012.net.il>; Sat, 26 Jan 2013 15:22:53 +0200 (IST) Date: Sat, 26 Jan 2013 15:23:02 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83ip6kjcy1.fsf@gnu.org> References: <83obgcjisd.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: shigeru.fukaya@gmail.com, 13553@debbugs.gnu.org > Date: Sat, 26 Jan 2013 07:40:08 -0500 > > > You call file-attributes, which encodes the file name and passes it to > > 'lstat'. The implementation of 'lstat' in w32.c then looks at the > > last byte of the encoded file name to see if there's a slash or > > backslash there. Boom! > > I see. So, does that meant that w32.c can't faithfully implement lstat > without doing the moral equivalent of re-decoding its argument? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4995] X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org, shigeru.fukaya@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: shigeru.fukaya@gmail.com, 13553@debbugs.gnu.org > Date: Sat, 26 Jan 2013 07:40:08 -0500 > > > You call file-attributes, which encodes the file name and passes it to > > 'lstat'. The implementation of 'lstat' in w32.c then looks at the > > last byte of the encoded file name to see if there's a slash or > > backslash there. Boom! > > I see. So, does that meant that w32.c can't faithfully implement lstat > without doing the moral equivalent of re-decoding its argument? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4481] > From: Stefan Monnier > Cc: shigeru.fukaya@gmail.com, 13553@debbugs.gnu.org > Date: Sat, 26 Jan 2013 07:40:08 -0500 > > > You call file-attributes, which encodes the file name and passes it to > > 'lstat'. The implementation of 'lstat' in w32.c then looks at the > > last byte of the encoded file name to see if there's a slash or > > backslash there. Boom! > > I see. So, does that meant that w32.c can't faithfully implement lstat > without doing the moral equivalent of re-decoding its argument? It can, if we limit such support to Windows codepage encodings. See the changes I made on the emacs-24 branch revisions 111194 and 111200. This will still lose if the user binds file-name-coding-system to something like shift_jis (instead of using its Windows extension cp932), but there's nothing I can do about that. I was lucky to find in Windows APIs 2 functions that can move forward and backward by DBCS characters, and that accept a codepage as their argument (i.e. do not limit support to the current system codepage). Personally, I think supporting all possible Windows codepages is good enough. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 09:07:07 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 14:07:07 +0000 Received: from localhost ([127.0.0.1]:50208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz6PR-0002Fc-GQ for submit@debbugs.gnu.org; Sat, 26 Jan 2013 09:07:05 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:59841) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz6PP-0002FB-9d for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 09:07:04 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MH800300KI7OO00@a-mtaout22.012.net.il> for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 16:06:38 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH8003OWKJ15NB0@a-mtaout22.012.net.il>; Sat, 26 Jan 2013 16:06:37 +0200 (IST) Date: Sat, 26 Jan 2013 16:06:47 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: <83libgje5t.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: shigeru.fukaya@gmail.com Message-id: <83fw1ojax4.fsf@gnu.org> References: <83libgje5t.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 26 Jan 2013 14:56:46 +0200 > From: Eli Zaretskii > Cc: 13553@debbugs.gnu.org > > After looking at the code which I fixed, I'm afraid I don't understand > why file-attributes returned nil in your case. The code that uses > IS_DIRECTORY_SEP there is only a fallback, for when the > GetFileInformationByHandle API fails for some reason. You don't say > what version of Windows you are using, but I won't expect that > fallback code be executed for any reasonably recent Windows version. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4998] X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 26 Jan 2013 14:56:46 +0200 > From: Eli Zaretskii > Cc: 13553@debbugs.gnu.org > > After looking at the code which I fixed, I'm afraid I don't understand > why file-attributes returned nil in your case. The code that uses > IS_DIRECTORY_SEP there is only a fallback, for when the > GetFileInformationByHandle API fails for some reason. You don't say > what version of Windows you are using, but I won't expect that > fallback code be executed for any reasonably recent Windows version. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4227] > Date: Sat, 26 Jan 2013 14:56:46 +0200 > From: Eli Zaretskii > Cc: 13553@debbugs.gnu.org > > After looking at the code which I fixed, I'm afraid I don't understand > why file-attributes returned nil in your case. The code that uses > IS_DIRECTORY_SEP there is only a fallback, for when the > GetFileInformationByHandle API fails for some reason. You don't say > what version of Windows you are using, but I won't expect that > fallback code be executed for any reasonably recent Windows version. Actually, that fallback code gets also executed if you customize w32-get-true-file-attributes to nil, or if the file is on a remote (i.e. networked) filesystem. Could one of these be true in your case? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 11:33:54 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 16:33:54 +0000 Received: from localhost ([127.0.0.1]:50599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz8hW-0005l5-1X for submit@debbugs.gnu.org; Sat, 26 Jan 2013 11:33:54 -0500 Received: from mail-da0-f47.google.com ([209.85.210.47]:34427) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz8hT-0005kx-P1 for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 11:33:52 -0500 Received: by mail-da0-f47.google.com with SMTP id s35so610445dak.20 for <13553@debbugs.gnu.org>; Sat, 26 Jan 2013 08:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:x-mailer:in-reply-to:references :message-id; bh=WWm4RZOfXXdolL0zCivk+AKhC8yjRb1ySOZ9fQXL7r0=; b=Xw7fN66cCDKfs3y8ahcGUwfwq4vcHPEqVPI66QD5bmCnd+Bl9sQpkTWdRHGxLj9Of8 ngs++zRbMSbnaXrWJ3k7GcvYzcXck4XPYNx1FHY2slFVdlBSzohmiHTWhE1mGZTuyDVI LuoQcWzy2zkUNZBjg8KiEUE4Bcmr/ZZEGbM4eA1zpCGq3Crbi0WGBMfBJFoQRlOqlzYI y829MQQts4/Pv7KiOMJ43RSRr+3GtSePBLggV2Zd644GL7ACszDzPldW4Iuexvf/60BT z/wJBL3PHd+Ygb5NLcpU/jh8hSOWVI5ZUuSE1FaJfIslzEhkDRCnUWh8ywOKkUKPal2q +9CA== X-Received: by 10.68.130.225 with SMTP id oh1mr23227022pbb.147.1359218016261; Sat, 26 Jan 2013 08:33:36 -0800 (PST) Received: from gmail.com (115x125x38x6.ap115.ftth.ucom.ne.jp. [115.125.38.6]) by mx.google.com with ESMTPS id pu5sm2804037pbb.73.2013.01.26.08.33.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 26 Jan 2013 08:33:34 -0800 (PST) From: Shigeru Fukaya To: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Date: Sun, 27 Jan 2013 01:33:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.00 (WinNT,601) In-Reply-To: <83libgje5t.fsf@gnu.org> References: <83libgje5t.fsf@gnu.org> Message-Id: X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) I greatly appreciate your very quick work, thank you. I looked through your fix of all functions (parse_root, get_volume_info, readdir, read_unc_volume, logon_network_drive, star_worker, symlink, chase_symlinks) one by one, and found good at first look. I'll try build and check it next, anyway. Yes, my `w32-get-true-file-attributes' is nil. (Isn't it default?) As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I suppose. But we need some notice for users. Regards, Shigeru >> From: Shigeru Fukaya >> Date: Sat, 26 Jan 2013 14:52:59 +0900 >> >> `file-attributes' returns nil as stat info for a file, its name ending >> with a character whose second byte is 0x5c. >> >> It is because IS_DIRECTORY_SEP is wrongly used. >> IS_DIRECTORY_SEP only works when its argument is surely on a start >> byte of dbcs characters. >> I find incorrect usage, at least in some functions of `w32.c'. >> (readdir, stat_worker, read_unc_volume) > >Thanks. I fixed w32.c functions that use IS_DIRECTORY_SEP in revision >111200 on the emacs-24 branch. As I cannot easily test DBCS file-name >encodings on my system, please test the fixed version and see if the >problem indeed goes away. The patch relative to emacs-24 branch is >below, for your convenience. > >After looking at the code which I fixed, I'm afraid I don't understand >why file-attributes returned nil in your case. The code that uses >IS_DIRECTORY_SEP there is only a fallback, for when the >GetFileInformationByHandle API fails for some reason. You don't say >what version of Windows you are using, but I won't expect that >fallback code be executed for any reasonably recent Windows version. > >So could you please trace through the code that file-attributes calls, >and see which use of IS_DIRECTORY_SEP caused the problem? I'm afraid >that it's not in w32.c at all, but elsewhere. > > >=== modified file 'src/w32.c' ... From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 12:38:41 2013 Received: (at 13553) by debbugs.gnu.org; 26 Jan 2013 17:38:41 +0000 Received: from localhost ([127.0.0.1]:50621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz9iC-0007KK-U3 for submit@debbugs.gnu.org; Sat, 26 Jan 2013 12:38:41 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:44063) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tz9i8-0007KA-SR for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 12:38:38 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MH800500U5KJI00@a-mtaout22.012.net.il> for 13553@debbugs.gnu.org; Sat, 26 Jan 2013 19:37:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH80051XUAZIS20@a-mtaout22.012.net.il>; Sat, 26 Jan 2013 19:37:48 +0200 (IST) Date: Sat, 26 Jan 2013 19:37:57 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Shigeru Fukaya Message-id: <83d2wrkfpm.fsf@gnu.org> References: <83libgje5t.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Shigeru Fukaya > Cc: 13553@debbugs.gnu.org > Date: Sun, 27 Jan 2013 01:33:32 +0900 > > I'll try build and check it next, anyway. Thank you. > Yes, my `w32-get-true-file-attributes' is nil. (Isn't it default?) [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4994] X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Shigeru Fukaya > Cc: 13553@debbugs.gnu.org > Date: Sun, 27 Jan 2013 01:33:32 +0900 > > I'll try build and check it next, anyway. Thank you. > Yes, my `w32-get-true-file-attributes' is nil. (Isn't it default?) The default is 'local', which means your local files use a different code path, one which doesn't need to use IS_DIRECTORY_SEP. If your value was nil, then I understand why the code I fixed could cause trouble. > As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I > suppose. But we need some notice for users. Not sure what you are saying here. Do you think many Japanese Windows users will set file-name-coding-system to shift_jis, or that most of them will set it to cp932? Normally, users don't customize file-name-coding-system at all, in which case Emacs will use default-file-name-coding-system, that is automatically set to cp932, according to the system-wide codepage. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 16:19:29 2013 Received: (at submit) by debbugs.gnu.org; 26 Jan 2013 21:19:29 +0000 Received: from localhost ([127.0.0.1]:50777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzD9t-00041a-0V for submit@debbugs.gnu.org; Sat, 26 Jan 2013 16:19:29 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35776) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzD9r-00041T-BF for submit@debbugs.gnu.org; Sat, 26 Jan 2013 16:19:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TzD9a-000839-8Z for submit@debbugs.gnu.org; Sat, 26 Jan 2013 16:19:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzD9a-000835-62 for submit@debbugs.gnu.org; Sat, 26 Jan 2013 16:19:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzD9Z-0001fq-2b for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 16:19:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TzD9Y-00082h-60 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 16:19:08 -0500 Received: from smtp207.alice.it ([82.57.200.103]:59330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzD9X-00082V-Ri for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 16:19:08 -0500 Received: from fmsmemgm.homelinux.net (82.107.57.105) by smtp207.alice.it (8.6.060.12) id 5102601400506BAD for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 22:19:06 +0100 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 8EE30AE3F4; Sat, 26 Jan 2013 16:19:05 -0500 (EST) Resent-Message-ID: Resent-To: bug-gnu-emacs@gnu.org Resent-From: Stefan Monnier Resent-Date: Sat, 26 Jan 2013 16:19:05 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 62F23AE3F4; Sat, 26 Jan 2013 07:40:08 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Message-ID: References: <83obgcjisd.fsf@gnu.org> Date: Sat, 26 Jan 2013 07:40:08 -0500 In-Reply-To: <83obgcjisd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Jan 2013 13:16:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: submit Cc: 13553@debbugs.gnu.org, shigeru.fukaya@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > You call file-attributes, which encodes the file name and passes it to > 'lstat'. The implementation of 'lstat' in w32.c then looks at the > last byte of the encoded file name to see if there's a slash or > backslash there. Boom! I see. So, does that meant that w32.c can't faithfully implement lstat without doing the moral equivalent of re-decoding its argument? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 26 19:21:17 2013 Received: (at submit) by debbugs.gnu.org; 27 Jan 2013 00:21:17 +0000 Received: from localhost ([127.0.0.1]:50866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzFzp-0008ML-BT for submit@debbugs.gnu.org; Sat, 26 Jan 2013 19:21:17 -0500 Received: from eggs.gnu.org ([208.118.235.92]:46580) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzFzn-0008MD-07 for submit@debbugs.gnu.org; Sat, 26 Jan 2013 19:21:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TzFzV-0004TX-8P for submit@debbugs.gnu.org; Sat, 26 Jan 2013 19:20:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:38164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzFzV-0004TT-5N for submit@debbugs.gnu.org; Sat, 26 Jan 2013 19:20:57 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzFzT-00085c-As for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 19:20:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TzFzS-0004Sz-93 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 19:20:55 -0500 Received: from smtp206.alice.it ([82.57.200.102]:56026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TzFzR-0004Sn-RE for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2013 19:20:54 -0500 Received: from fmsmemgm.homelinux.net (82.107.57.105) by smtp206.alice.it (8.6.058.01) id 508F91B90D5102C3 for bug-gnu-emacs@gnu.org; Sun, 27 Jan 2013 01:20:52 +0100 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id ACCD7AE3F4; Sat, 26 Jan 2013 19:20:51 -0500 (EST) Resent-Message-ID: Resent-To: bug-gnu-emacs@gnu.org Resent-From: Stefan Monnier Resent-Date: Sat, 26 Jan 2013 19:20:51 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 17815AE3F4; Sat, 26 Jan 2013 17:24:37 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Message-ID: References: <83obgcjisd.fsf@gnu.org> <83ip6kjcy1.fsf@gnu.org> Date: Sat, 26 Jan 2013 17:24:37 -0500 In-Reply-To: <83ip6kjcy1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 26 Jan 2013 15:23:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit Cc: 13553@debbugs.gnu.org, shigeru.fukaya@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) >> > You call file-attributes, which encodes the file name and passes it to >> > 'lstat'. The implementation of 'lstat' in w32.c then looks at the >> > last byte of the encoded file name to see if there's a slash or >> > backslash there. Boom! >> I see. So, does that meant that w32.c can't faithfully implement lstat >> without doing the moral equivalent of re-decoding its argument? > It can, if we limit such support to Windows codepage encodings. See > the changes I made on the emacs-24 branch revisions 111194 and 111200. CharNextExA and CharPrevExA, in my mind, do perform the moral equivalent of decoding the argument (just in an incremental way). > Personally, I think supporting all possible Windows codepages is > good enough. Fine by me, Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 01:57:22 2013 Received: (at 13553) by debbugs.gnu.org; 27 Jan 2013 06:57:22 +0000 Received: from localhost ([127.0.0.1]:50969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMB6-0001SR-9Y for submit@debbugs.gnu.org; Sun, 27 Jan 2013 01:57:21 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:46548) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMB2-0001SI-Uf for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 01:57:18 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz11so965643pad.3 for <13553@debbugs.gnu.org>; Sat, 26 Jan 2013 22:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:x-mailer:in-reply-to:references :message-id; bh=V+JQ8bk+zbpl+XsuKg+I0mIMT0rJDe+qiPOoBZzGKpM=; b=UP6x4mqYlxRqi+GeXXwwU8ZmImO5oHqom1HUt+Dps5GuyBxirrpFyOCJMY9cGUjh7x 3O/DPDLui81aL42FJ5CpMxYNGfYNhqsN5qO7Jsso5HK27rUGvMvMHWbqgsO+sIDQIH7l 7/Aq+aXZK/Envnm7wKlo0R9yTe4vIvJvoZu024sgtmCk0qTUE5LOARhxRyUnA56p/8XD QuqMko4SGVQuD56HThAg67uBvgQ5zRLTTzfhy8HhH+QA03KSELpP6OyGEPB9lTuWp0Lj vXR7Q2Jpa4AuwkKRbInbj2xlq2skGkBPFIV4DOoc0RQOaOp3tedcubkJ30UCQIgbLY9j GVJQ== X-Received: by 10.66.83.136 with SMTP id q8mr26251794pay.83.1359269818077; Sat, 26 Jan 2013 22:56:58 -0800 (PST) Received: from gmail.com (115x125x38x6.ap115.ftth.ucom.ne.jp. [115.125.38.6]) by mx.google.com with ESMTPS id qm9sm3903408pbc.10.2013.01.26.22.56.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 26 Jan 2013 22:56:56 -0800 (PST) From: Shigeru Fukaya To: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Date: Sun, 27 Jan 2013 15:56:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.00 (WinNT,601) In-Reply-To: <83d2wrkfpm.fsf@gnu.org> References: <83libgje5t.fsf@gnu.org> <83d2wrkfpm.fsf@gnu.org> Message-Id: X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) Built on migw32, and no trouble, thank you (I didn't do coverage tests, sorry). But we must remember, my raise of issue is the incorrect usage of IS_DIRECTORY_SEP. There are still more in fileio.c and more. (I really expect remove the check of '\' from IS_DIRECTORY_SEP, and handle '\' only where it is necessary, and things wolud be better) >> As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I >> suppose. But we need some notice for users. > >Not sure what you are saying here. Do you think many Japanese Windows >users will set file-name-coding-system to shift_jis, or that most of >them will set it to cp932? > >Normally, users don't customize file-name-coding-system at all, in >which case Emacs will use default-file-name-coding-system, that is >automatically set to cp932, according to the system-wide codepage. Yes, you are right. I mean, maybe, the case of using some remote file system. You can check by yourself their (our?) usage if you like. Some seems still using shift-jis, not cp932. http://www.google.co.jp/search?q=file-name-coding-system+sjis Regards, Shigeru From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 02:06:59 2013 Received: (at 13553) by debbugs.gnu.org; 27 Jan 2013 07:06:59 +0000 Received: from localhost ([127.0.0.1]:50975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMKR-0001ff-8q for submit@debbugs.gnu.org; Sun, 27 Jan 2013 02:06:59 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:64617) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMKO-0001fX-MO for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 02:06:57 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MH900A00VNEGZ00@a-mtaout21.012.net.il> for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 09:06:29 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH900ARFVQS5CA0@a-mtaout21.012.net.il>; Sun, 27 Jan 2013 09:06:29 +0200 (IST) Date: Sun, 27 Jan 2013 09:06:40 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <8338xnje9r.fsf@gnu.org> References: <83obgcjisd.fsf@gnu.org> <83ip6kjcy1.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org, shigeru.fukaya@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: shigeru.fukaya@gmail.com, 13553@debbugs.gnu.org > Date: Sat, 26 Jan 2013 17:24:37 -0500 > > CharNextExA and CharPrevExA, in my mind, do perform the moral equivalent > of decoding the argument (just in an incremental way). No, they are the equivalents of NEXT_CHAR_BOUNDARY and PREV_CHAR_BOUNDARY, except that they can do this for many different encodings, not just for UTF-8. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 02:16:09 2013 Received: (at 13553-done) by debbugs.gnu.org; 27 Jan 2013 07:16:09 +0000 Received: from localhost ([127.0.0.1]:50981 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMTJ-0001sI-4I for submit@debbugs.gnu.org; Sun, 27 Jan 2013 02:16:09 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:62741) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzMTF-0001s7-6c for 13553-done@debbugs.gnu.org; Sun, 27 Jan 2013 02:16:06 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MH900C00W039C00@a-mtaout20.012.net.il> for 13553-done@debbugs.gnu.org; Sun, 27 Jan 2013 09:15:33 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH900CAJW5W3L40@a-mtaout20.012.net.il>; Sun, 27 Jan 2013 09:15:33 +0200 (IST) Date: Sun, 27 Jan 2013 09:15:45 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Shigeru Fukaya Message-id: <831ud7jdum.fsf@gnu.org> References: <83libgje5t.fsf@gnu.org> <83d2wrkfpm.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Shigeru Fukaya > Cc: 13553@debbugs.gnu.org > Date: Sun, 27 Jan 2013 15:56:54 +0900 > > Built on migw32, and no trouble, thank you > (I didn't do coverage tests, sorry). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4992] X-Debbugs-Envelope-To: 13553-done Cc: 13553-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Shigeru Fukaya > Cc: 13553@debbugs.gnu.org > Date: Sun, 27 Jan 2013 15:56:54 +0900 > > Built on migw32, and no trouble, thank you > (I didn't do coverage tests, sorry). Thanks. I'm therefore closing this bug. > But we must remember, my raise of issue is the incorrect usage of > IS_DIRECTORY_SEP. There are still more in fileio.c and more. Yes. This is being discussed on emacs-devel, and once that discussion ends, the fileio.c and dired.c functions will be fixed as well. > >> As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I > >> suppose. But we need some notice for users. > > > >Not sure what you are saying here. Do you think many Japanese Windows > >users will set file-name-coding-system to shift_jis, or that most of > >them will set it to cp932? > > > >Normally, users don't customize file-name-coding-system at all, in > >which case Emacs will use default-file-name-coding-system, that is > >automatically set to cp932, according to the system-wide codepage. > > Yes, you are right. I mean, maybe, the case of using some remote file > system. Accessing remote files doesn't go through functions in w32.c, it goes through file handlers (in Tramp). > You can check by yourself their (our?) usage if you like. > Some seems still using shift-jis, not cp932. > > http://www.google.co.jp/search?q=file-name-coding-system+sjis If they want 100% solid support, they will have to change their customizations, sorry. (We could implement an equivalence table, whereby, e.g., shift_jis would be mapped to cp932, but these encodings are slightly different, so I think that would be a kludge.) In any case, the new code in w32.c is no worse than the previous one, when file-name-coding-system is set to anything that is not a recognized Windows codepage. It is actually slightly better: it uses the system-wide ANSI codepage in that case. In most cases, this would be the right thing anyway. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 03:37:13 2013 Received: (at 13553) by debbugs.gnu.org; 27 Jan 2013 08:37:13 +0000 Received: from localhost ([127.0.0.1]:50998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzNjk-0004BA-UW for submit@debbugs.gnu.org; Sun, 27 Jan 2013 03:37:13 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:63664) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzNji-0004B3-OU for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 03:37:11 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz11so983907pad.3 for <13553@debbugs.gnu.org>; Sun, 27 Jan 2013 00:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:x-mailer:in-reply-to:references :message-id; bh=ujahwvaBDnAho5PPSn57snCREvtM8ZbUr+MFqGDTpvQ=; b=ZS495ntb9ybOPhL9nfG2JjDRuINvT4efQf9gB/Ig+22lMHBi7jimIgc+P8t4yOsZ7d TQeyR8+OMGFKNpI0P6hINqiNMHgCAB6X+jwImk81Nb4uTS1isLpWWbFOFQT810nvmyqp PY1O2F34lbsx4kGvXDepJp8D8xi2Fx38xFt7ds5co3ABKaxnnN+CGgM1e1BCPnOJSoR3 B1m8ytlOiZP5Lz2BT86audLOK0ur9djwHrzxDeiM2qzil8o3xBniOWiXoZjn1U/PwDu2 HpVA7k7s7xAnOzZLrLpTOGMPi5UYXqKK/UmjOIwDsuq9ebCQLlvVqc8rJSrYMpNxp98O IL2A== X-Received: by 10.68.237.135 with SMTP id vc7mr28185738pbc.2.1359275811413; Sun, 27 Jan 2013 00:36:51 -0800 (PST) Received: from gmail.com (115x125x38x6.ap115.ftth.ucom.ne.jp. [115.125.38.6]) by mx.google.com with ESMTPS id jo6sm4038342pbb.5.2013.01.27.00.36.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 00:36:49 -0800 (PST) From: Shigeru Fukaya To: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP Date: Sun, 27 Jan 2013 17:36:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.00 (WinNT,601) In-Reply-To: <8338xnje9r.fsf@gnu.org> References: <83ip6kjcy1.fsf@gnu.org> <8338xnje9r.fsf@gnu.org> Message-Id: X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) One more, please. CharNextExA/CharPrevExA work based on dynamically specified codepage. And, _mbspbrk/_mbslwr are also used in w32.c. They work based on MS Window's locale setting. Isn't it inconsistent? _mbsinc/_mbsdec would simply be sufficient? (Besides, I don't know well, _mbslwr seems to me lower latin characters' case on some locale. Is it true, or intended behavior?) Thank you, Shigeru >> From: Stefan Monnier >> Cc: shigeru.fukaya@gmail.com, 13553@debbugs.gnu.org >> Date: Sat, 26 Jan 2013 17:24:37 -0500 >> >> CharNextExA and CharPrevExA, in my mind, do perform the moral equivalent >> of decoding the argument (just in an incremental way). > >No, they are the equivalents of NEXT_CHAR_BOUNDARY and >PREV_CHAR_BOUNDARY, except that they can do this for many different >encodings, not just for UTF-8. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 27 04:40:18 2013 Received: (at 13553) by debbugs.gnu.org; 27 Jan 2013 09:40:18 +0000 Received: from localhost ([127.0.0.1]:51011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzOio-0005d2-6D for submit@debbugs.gnu.org; Sun, 27 Jan 2013 04:40:18 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:47856) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TzOii-0005cn-D8 for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 04:40:14 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MHA009002PSVU00@a-mtaout23.012.net.il> for 13553@debbugs.gnu.org; Sun, 27 Jan 2013 11:39:51 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHA0090C2UENB80@a-mtaout23.012.net.il>; Sun, 27 Jan 2013 11:39:50 +0200 (IST) Date: Sun, 27 Jan 2013 11:40:03 +0200 From: Eli Zaretskii Subject: Re: bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP In-reply-to: X-012-Sender: halo1@inter.net.il To: Shigeru Fukaya Message-id: <83y5ffhslo.fsf@gnu.org> References: <83ip6kjcy1.fsf@gnu.org> <8338xnje9r.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13553 Cc: 13553@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: Shigeru Fukaya > Cc: Stefan Monnier , > 13553@debbugs.gnu.org > Date: Sun, 27 Jan 2013 17:36:48 +0900 > > CharNextExA/CharPrevExA work based on dynamically specified codepage. > > And, _mbspbrk/_mbslwr are also used in w32.c. They work based on MS > Window's locale setting. > > Isn't it inconsistent? It is, but I don't know of any practical way of eliminating that inconsistency. In the normal case, where the current file-name-coding-system is the same as the ANSI codepage, there is no inconsistency, so using CharNextExA/CharPrevExA is never worse than using _mbsinc/_mbsdec. It is sometimes better, because the code which calls the _mbs* functions is executed only by some functions in w32.c. > _mbsinc/_mbsdec would simply be sufficient? That would preclude code like this: (let ((file-name-coding-system 'cp932)) (expand-file-name "SOMETHING" "C:/") I think it's reasonable to expect this to be supported, even if the default file-name encoding is not cp932. > (Besides, I don't know well, _mbslwr seems to me lower latin > characters' case on some locale. Is it true, or intended behavior?) The intended behavior is to downcase letters for which lower-case is defined. I don't know if this is limited to Latin characters. From unknown Sat Jun 14 19:40:55 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 24 Feb 2013 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator