From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `rename-file' with leading spaces in filename Date: Fri, 30 Dec 2005 20:41:30 +0200 Message-ID: References: <43B54224.7000703@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1135968639 24088 80.91.229.2 (30 Dec 2005 18:50:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2005 18:50:39 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 19:50:37 2005 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 1EsPKT-00011Z-KA for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2005 19:50:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EsPLt-00009S-8t for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2005 13:51:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EsPDQ-0001z2-Hs for emacs-devel@gnu.org; Fri, 30 Dec 2005 13:43:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EsPDP-0001xs-HO for emacs-devel@gnu.org; Fri, 30 Dec 2005 13:42:59 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EsPDP-0001xl-AD for emacs-devel@gnu.org; Fri, 30 Dec 2005 13:42:59 -0500 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EsPDy-0003aa-4d for emacs-devel@gnu.org; Fri, 30 Dec 2005 13:43:34 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-31-198.inter.net.il [80.230.31.198]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CHZ93614 (AUTH halo1); Fri, 30 Dec 2005 20:41:28 +0200 (IST) Original-To: martin rudalics In-reply-to: <43B54224.7000703@gmx.at> (message from martin rudalics on Fri, 30 Dec 2005 15:20:20 +0100) 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:48551 Archived-At: > Date: Fri, 30 Dec 2005 15:20:20 +0100 > From: martin rudalics > > With GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000): > > Suppose I have a file called "c:/foo" > > Doing M-x rename-file RET c:/foo RET c:/ foo > M-x rename-file RET c:/ foo RET c:/foo > > gets me: > > File c:/foo already exists; rename to it anyway? (y or n) > > After confirmation Emacs renames as expected, the behavior is, however, > inconsistent since the first rename didn't ask for a confirmation. 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. In a sense, these two names are like hard links on Posix systems: they both point to the same data on disk. If I'm right, then Emacs is not to blame, since the target file indeed exists (although in this case, no harm would be done by renaming, since you are renaming the same file). > Suppose now I have two files called "c:/ foo" (one leading space) > and "c:/ foo" (two leading spaces). > > Doing M-x rename-file RET c:/ foo RET c:/foo > > gets me: > > File c:/foo already exists; rename to it anyway? (y or n) > > If I now confirm, the file "c:/ foo" (two leading spaces) is deleted and > "c:/ foo" (one leading space) renamed to "c:/foo". That's unfriendly. Patient: Doctor, it hurts when I do like this. Doctor: Well, then don't do that! Seriously, though: you _have_ been warned that you are going to overwrite an existing file, you decided to go ahead anyway, and now you complain? If I were you, I'd first visit "c:/foo" and would decide whether to overwrite it depending on what contents I saw. What happens is this: both "c:/ foo" and "c:/ foo" map to the same short alias "c:/foo". So, to solve the name clash, Windows generates numeric tails, so one of the two files (or both) has its short alias as "c:/foo~2" or some such. Which one of the two maps to "c:/foo" depends on which one was created first. In your case, it sounds like it was "c:/ foo"; it could be the other way around. When you rename "c:/ foo", it nukes "c:/foo", whose data is the one you referred to as "c:/ foo". 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.