I was using Windows 7 x64. Sometimes I worked in Windows Explorer. More commonly, I used Explorer++. For some reason, Explorer++ suddenly began handling files differently. This post describes what I tried and how I got a solution.
Incidentally, this problem was not limited to Explorer++. I saw that a few people seemed to be having the same problem in Windows Explorer. I, myself, was not having the problem in Windows Explorer. I was not sure whether similar steps would work for those using Windows Explorer.
The problem I encountered was as follows. In the desired procedure, I would copy or cut a file from one folder, and I would paste it into another folder. If there was another file of the same name in the target folder, I would get a dialog like this:
That is, the system would give me the option of overwriting (i.e., the incoming file would replace the one already in the target folder), or not moving, or moving and keeping both. But now that wasn’t happening. There would be no dialog presenting options. Instead, both files would exist in the target folder by default. One would have its original name (e.g., Original File.txt), and the other would have ” – Copy” appended to its name (e.g., Original File – Copy.txt). I wanted to return to the previous arrangement, where I would get that dialog offering overwrite options.
I found an Explorer++ discussion thread that said the problem was going to be fixed circa 2010. Apparently it had been fixed, and I had been using the new and improved version. It seemed that perhaps my installation had been damaged, though, so possibly I would be well advised to uninstall and reinstall. It looked like there was a newer version available for download, so I went with that.
While downloading, I noticed that Explorer++ was still available solely as a portable, so I wouldn’t actually be installing it per se; I would just be unzipping it and putting the executable (Explorer++.exe) in the desired location. In my case, that would be my customized, shareable Start Menu.
I couldn’t just cut and paste the newly downloaded and unzipped executable (and its accompanying license and other text files) in the desired location, unfortunately — because, ha ha, when I did, the files would be saved with ” – Copy” appended to their names. I had to delete the previous files before moving the new ones in to take their place (and of course I had to shut down Explorer++ before doing that). In other words, this operation was best handled in Windows Explorer. I made sure not to delete the old config.xml file, since that contained my customized Explorer++ settings.
Unfortunately, this was not the solution. With the new version of Explorer++ in place, the copy-rather-than-replace behavior persisted. I checked the Options for the new version of Explorer++ but did not see anything relevant. This suggested that perhaps the problem was not in Explorer++ but was rather in Windows itself — although that would raise the question of why I was not presently having this problem in Windows Explorer.
I went back to the search I had started when first perusing the situation. As I read various posts that came up under that search, I wondered whether it would make a difference if I went to Desktop > right-click on Recycle Bin > Properties > check the “Display delete confirmation dialog” box. I thought maybe I could work with that for a few minutes, and then uncheck it again, and possibly that would fix something. But with that box unchecked, this behavior remained unchanged; it just asked me for verification before actually deleting something.
I took a look at Ultimate Windows Tweaker, in case it contained a tweaking option that could repair this situation. It didn’t, though I did change a few other things while I was there.
If this unwanted behavior was due to some new change in Windows itself, as distinct from Explorer++, then I suspected the cause was the new Windows updates that I had just installed a few hours earlier. In that case, rolling the system back to a prior state should solve the problem. I went into System Restore (rstrui.exe) and chose a restore point from the previous day. I closed all programs, temporarily disabled my antivirus so that System Restore would succeed, ran that restore, let the system reboot, and tried the file copying operation again. That was not the solution: the problem was still there.
So I was back at the hypothesis that it was a problem with Explorer++. It belatedly occurred to me to try the same operation in FreeCommander, another Windows Explorer replacement. There, it worked as expected, with a dialog confirming that I wanted to overwrite the target file.
Another search led to a post from January 2011, expressing again a concern about this behavior. No solution was offered; others weren’t having this problem, and indeed the search had come up with only a few hits. There was a suggestion in that thread that perhaps the problem was due to some kind of setting change outside of Explorer++. I was willing to believe that but, at this writing, I was not sure what that setting would be.
As I thought about it, I wondered whether perhaps the problem was within my config.xml file. That file was created by Explorer++, the first time I ran it; it saved the Explorer++ settings; and it was the one file that I had preserved from my previous version, when upgrading to this latest download. To try out that possibility, I shut down Explorer++, temporarily removed config.xml from the folder where I had placed explorer++.exe, and then restarted Explorer++. Eureka! That was the solution: now, when I tried to paste a file into a folder where an identically named file already existed, I got the dialog saying,
There is already a file with the same name in this location.
Click the file you want to keep
So it seemed there was something wrong in my config.xml file. Fortunately, I had old copies of my config.xml file, so I could compare the old and the new for changes. To get Microsoft Word 2010 to see these as plain text rather than as XML files, I had to open copies of these old and new config.xml files in Notepad and do a global removal (Ctrl-H) of all “<” and “>” signs. I saved those altered files. Then, in Word, I compared them, using Compare in Word’s Review tab. This highlighted several changes. It seemed my answer might be in the OverwriteExistingFilesConfirmation setting. It was set to “no.” There wasn’t an instruction manual detailing each setting’s options. A search led back to my own previous post, where I saw that it had been set to “yes.” I had no idea how that would have gotten changed.
I opened the currently operable config.xml (i.e., the one in the same folder as explorer++.exe) and changed that setting to “yes.” Explorer++ was open at the time. I wasn’t sure what I would have to do, to get it to recognize the change. It didn’t work immediately, so I closed and restarted Explorer++ and tried again. That didn’t do it either, and now I saw that the setting had been switched back to “no” in config.xml. Evidently Explorer++ maintained a copy of its current settings in RAM, and used those to update config.xml when Explorer++ closed. So this time I closed Explorer++ first, made the change in config.xml, and then restarted Explorer++. That did it: I had my overwrite confirmation dialog again, when I would cut or copy a file from one folder to another. Problem solved. I posted a note on it on the Explorer++ forum and moved on.