From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: `rename-file' with leading spaces in filename Date: Mon, 02 Jan 2006 10:48:59 +0100 Message-ID: <43B8F70B.3000001@gmx.at> References: <43B54224.7000703@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1136202456 1801 80.91.229.2 (2 Jan 2006 11:47:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2006 11:47:36 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 02 12:47:28 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EtO9g-00088K-RJ for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2006 12:47:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtNgd-0000hX-6X for ged-emacs-devel@m.gmane.org; Mon, 02 Jan 2006 06:17:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EtN0h-0003k6-Nu for emacs-devel@gnu.org; Mon, 02 Jan 2006 05:33:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EtMud-00033N-FJ for emacs-devel@gnu.org; Mon, 02 Jan 2006 05:28:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtMtX-0002wz-2E for emacs-devel@gnu.org; Mon, 02 Jan 2006 05:26:29 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1EtMuY-0007NX-LX for emacs-devel@gnu.org; Mon, 02 Jan 2006 05:27:31 -0500 Original-Received: (qmail invoked by alias); 02 Jan 2006 10:24:47 -0000 Original-Received: from N775P015.adsl.highway.telekom.at (EHLO [62.47.40.207]) [62.47.40.207] by mail.gmx.net (mp001) with SMTP; 02 Jan 2006 11:24:47 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: Eli Zaretskii In-Reply-To: X-Y-GMX-Trusted: 0 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:48619 Archived-At: Thanks for the delightful response. > I don't have access to Windows 9x/ME anymore to verify my guess, but I > think I know what is the reason: it's the fact that Windows 9x > generates a 8+3 alias for every file whose name violates the DOS > file-naming constraints. > The Windows algorithm for generating the 8+3 alias begins with > removing all the whitespace characters from the file name, and then > replaces the other invalid characters with `_' and truncates the > result to 8+3 limits. This makes short alias for "c:/ foo" to be -- > ta-da! -- "c:/foo". You should be able to verify that by looking at > the output of the DIR command built into command.com, which shows the > 8+3 alias next to the long file name. Your guess is precise. It wouldn't have come into my mind that Windows does _not_ tildify when there are 8+3 offenders and all of them are spaces. The renaming problem occurs when there's a short alias that does not have a tilde and an offending long name maps to that alias. By the way look at the dir output below: FOO 10 02.01.06 8:16 foo FOO~1 13 02.01.06 8:19 foo FOO~ 13 02.01.06 8:13 foo~ FOO~ 10 02.01.06 7:45 foo~ The funny thing here is that the backups have identic short aliases. When I `find-file-noselect' " foo~" or " foo~" Emacs opens the correct file. When I `find-file-noselect' the non-existent "foo~" Emacs opens " foo~" instead. > Windows NT and its descendants, including XP which I run, > don't have this problem, because I think they don't store short > aliases on the disk in the same way as Windows 9x does. Maybe because FAT32 records file names in the order they have been created and NTFS records them alphabetically. However, I believe that FindFirstFile may return the short alias regardless of the file system employed and/or whether Unicode is used. Hence I wouldn't rely on XPs never running into a similar problem. To solve this problem for me I'd probably have to compare `cFileName' with the name FindFirstFile was looking for. If these match, the file should really exist and I'd issue the standard warning. Otherwise, I'd temporarily rename the file referenced by `cAlternateFileName', do the renaming I intended, and re-rename the temporary one. Essentially what `sys_rename' does for Windows 95.