From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MJ Chan Newsgroups: gmane.emacs.devel Subject: Re: file-attribute on certain Chinese filenames failed Date: Tue, 13 Feb 2007 01:06:39 -0500 Message-ID: <17873.21871.414000.223392@MJ.T40.T40> References: <45c9d948.5c6acfa4.4c9b.ffffeb01@mx.google.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1171464140 1388 80.91.229.12 (14 Feb 2007 14:42:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2007 14:42:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 14 15:42:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HHLKg-0007np-5R for ged-emacs-devel@m.gmane.org; Wed, 14 Feb 2007 15:42:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HHLKf-0000Uy-LY for ged-emacs-devel@m.gmane.org; Wed, 14 Feb 2007 09:42:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HGqoQ-0007wu-On for emacs-devel@gnu.org; Tue, 13 Feb 2007 01:06:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HGqoP-0007vq-MT for emacs-devel@gnu.org; Tue, 13 Feb 2007 01:06:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HGqoP-0007vJ-EY for emacs-devel@gnu.org; Tue, 13 Feb 2007 01:06:45 -0500 Original-Received: from wx-out-0506.google.com ([66.249.82.236]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HGqoO-0002lR-Rw for emacs-devel@gnu.org; Tue, 13 Feb 2007 01:06:45 -0500 Original-Received: by wx-out-0506.google.com with SMTP id s17so2069550wxc for ; Mon, 12 Feb 2007 22:06:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:content-transfer-encoding:message-id:date:from:to:cc:subject:x-signature:in-reply-to:references:x-spam-processed:x-mdremoteip:x-return-path:x-mdaemon-deliver-to; b=BV1Hk2W0p2BmBjFqk3Pce+333N9I5/KRjr7ZIKjwZCZIS1Y/50yhFII07WaaaDLBmtkPGLULDDqnOqf5grzBUnSFolwyrY8tu18kn4AyRcq642XMDMj38TsXtJHUP+9fnE1q0ENgqCS0ZmkeJwB+NmcKRjTG9SMEaU+jNWQ2U1A= Original-Received: by 10.90.51.17 with SMTP id y17mr18519554agy.1171346804088; Mon, 12 Feb 2007 22:06:44 -0800 (PST) Original-Received: from greenplace.page.us ( [69.138.161.132]) by mx.google.com with ESMTP id 45sm15941327wri.2007.02.12.22.06.43; Mon, 12 Feb 2007 22:06:44 -0800 (PST) Original-Received: from T40 ([127.0.0.1]) by local (greenplace.page.us [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 31-md50000000002.tmp for ; Tue, 13 Feb 2007 01:06:40 -0500 X-Signature: mjchan 1e7039c143c9c7f50ab35a7053107bd9 In-Reply-To: X-Spam-Processed: greenplace.page.us, Tue, 13 Feb 2007 01:06:40 -0500 (not processed: spam filter disabled) X-MDRemoteIP: 127.0.0.1 X-Return-Path: mjchan.inbox@gmail.com X-MDaemon-Deliver-To: emacs-devel@gnu.org X-detected-kernel: Linux 2.4-2.6 (Google crawlbot) X-Mailman-Approved-At: Wed, 14 Feb 2007 09:41:23 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:66378 Archived-At: Thanks for looking into the problem.=20 The same code you used did not cause write-region to fail on my XP. That is, the file "=B7|" was written correctly. But again, file-attributes returned nil. Also, if I use utf-8, then file-attributes reports incorrectly the file as a directory as shown below. This is odd. (let ((file-name-coding-system 'utf-8)) (file-attributes "=B7|")) =3D> (t 1 5 5 (17873 20762) (17873 20755) (17430 62310) 0 "drwxrwxrwx" = nil 0 (41075 . 32279)) (let ((file-name-coding-system 'big5)) (file-attributes "=B7|")) =3D> nil If you have other clue, please let me know. BTW, My machine is running English XP with Big5 (Chinese/Taiwan) set fo= r non-Unicode program in Regional and Language Options in Control Panel. >>>>> On Tuesday, February 13 2007, Kenichi Handa said: > In article <45c9d948.5c6acfa4.4c9b.ffffeb01@mx.google.com>, MJ Ch= an writes: >> I had trouble in accessing some files that contains certain Chin= ese >> (big5) characters (in fact, I found only one character so far th= at is >> causing the problem; all others are good). After checking around= , I >> found that the problem would take place in "lstat" call in the C= >> source. One example is in "file-attributes" (src/dired.c). >> For example, if I created a file named "=3D26345" (see below for= the >> "describe-char" on that particular Chinese character) and then >> evaluated this, it returned nil.=20 >> (file-attributes "=3D26345") >> nil > I can't reproduce that problem on GNU/Linux. For instance, > it seems that this code work correctly. > (let ((file-name-coding-system 'big5) > (filename (string #x26345))) > (with-temp-file filename (insert "abc\n")) > (file-attributes filename)) > =3D> (nil 1 8308 8308 (17873 19356) (17873 19356) (17873 19356) > 4 "-rw-rw-r--" nil 11175288 21) > But, when I run the same code on Windows, write-region > causes this error: > (file-error "Opening output file" "invalid argument" > "c:/cygwin/home/handa/\x26345") > I suspect that this is because the big5 sequence of the > character #x26345 is "\267|", and Windows-XP (at least my > Japanese version) doesn't allow creating a file containing > "|". For instance, I can't create a file "a|" either. >> As mentioned above, the culprit seems to be in calling lstat wit= h >> encoded version of the file name as shown below (taken from dire= d.c) >> GCPRO1 (filename); >> encoded =3D ENCODE_FILE (filename); >> UNGCPRO; >> if (lstat (SDATA (encoded), &s) < 0) >> return Qnil; >> If I changed the call to use un-encoded filename (i.e. lstat >> (filename,...)), then it is good. But I am not sure if this is t= he >> right thing to do.=20 > I believe it's not the right fix, and first of all, I have > no idea why such a change fixes your case. > Anyway, it seems that this is an Windows specific problem. > --- > Kenichi Handa > handa@m17n.org