emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `rename-file' with leading spaces in filename


From: Eli Zaretskii
Subject: Re: `rename-file' with leading spaces in filename
Date: Fri, 30 Dec 2005 20:41:30 +0200

> Date: Fri, 30 Dec 2005 15:20:20 +0100
> From: martin rudalics <address@hidden>
> 
> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]