# Why does Windows XP (during a rename operation) report file already exists when it doesn't?

From the command-line:

E:\menu\html\tom\val\.svn\tmp\text-base>ver

Microsoft Windows [Version 5.2.3790]

Volume in drive E is DATA
Volume Serial Number is F047-F44B

12/23/2010  04:36 PM    <DIR>          .
12/23/2010  04:36 PM    <DIR>          ..
12/23/2010  04:01 PM                 0 wtf.com3.csv.svn-base
1 File(s)              0 bytes
2 Dir(s)  170,780,262,400 bytes free

A duplicate file name exists, or the file
cannot be found.

Volume in drive E is DATA
Volume Serial Number is F047-F44B

12/23/2010  04:36 PM    <DIR>          .
12/23/2010  04:36 PM    <DIR>          ..
12/23/2010  04:01 PM                 0 wtf.com3.csv.svn-base
1 File(s)              0 bytes
2 Dir(s)  170,753,064,960 bytes free

Volume in drive E is DATA
Volume Serial Number is F047-F44B



I don't know what to do about this, as there is no other file in this directory. Why does Windows XP report that there is already a file here named com3.csv.svn-base when there is clearly no other file here?

UPDATE: This is happening on my work machine, WinXP 64-bit. But it also fails on my home machine, WinXP 32-bit. However, in linux, it works just fine. Maybe this is an NTFS filesystem bug?

-
Have you had a chance to check my answer? – mfinni Dec 29 '10 at 21:42

Ding ding ding.

Windows and DOS have device names reserved as filenames that are present in every directory. COM3 is one of them. You're probably familiar with NUL, LPT1, CON (like COPY CON) etc. Your problem is that you're trying to rename it to COM3.anything.anything. Windows, which still has some DOS-era backwards compatabilities, will not allow you to name a file in a way to break that.

Wikipedia tells me that you should be able to use a long UNC like \\mycomputer\E\$\menu\html\tom\val\.svn\tmp\text-base\com3.csv.svn-base as your rename target.

-
That's it! You really know your stuff. I couldn't get the alternate method rename to work, but that's okay as we killed the evil file anyway (took out the entire \val tree, actually) and now all is well. Had no idea that these reserved terms affected filenames like this. Brings back memories. – user60917 Dec 29 '10 at 22:30
Definitely a tip o' the hat to Jason Berg below; when he asked that, it tripped my memory about the reserved filenames. – mfinni Dec 29 '10 at 22:34

Could there be a hidden file in the directory? Try "dir /ah" to show all hidden files. If there are no hidden files, run "chkdsk /f e:" to check for filesystem problems (this may require a reboot). If that doesn't fix the problem, you may have bad sectors o the hard drive. Run "chkdsk /r e:" to check for bad sectors.

-
Thanks for the tips. I have a chkdsk scheduled for next reboot, but that's going to be a while. I'll update when I know more. – user60917 Dec 24 '10 at 1:28
+1 to parent. Also note that later OS versions (Vista/Server 2008 and above) can repair many NTFS issues live, without requiring a reboot. Just sayin' – Jeff McJunkin Dec 24 '10 at 6:26
rebooting and running the chkdsk did not help. same exact error with same exact non-existent file. I've never seen this before. – user60917 Dec 27 '10 at 23:52
Thanks for saying "hidden file"; that's what prompted me to remember the really-fricking-hidden device names that are always present but never listed. – mfinni Dec 28 '10 at 22:15