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

[martin rudalics]

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.