When I use the RMDIR command in my batch files immediately followed by the IF statement to check to see if the directory has been removed, the result is that the directory is not removed. It appears that the IF statement starts execution before the RMDIR command completes its processing. This does not happen with Windows XP. And it should not happen in any operating system.

Are you sure that the folder is actually removed? Maybe the folder still exists because you do not have permissions to remove it. In this case you may need to run the batch file as administrator. Arthur Xie - MSFT

One additional thing... Are you sure you have your RMDIR command syntax correct? It might help to post a snippet of your batch file here for other eyes to review. -Noel

What sounds like is happening is that you're running a console command line application (e.g., rmdir.exe) rather than a built-in command. Under some conditions console applications can start but the command processor will not wait for them to finish unless you use the START /WAIT command prefix. Do you, by chance, have the Gnu Toolkit installed? It has an rmdir command in it, and it will even work in the simple case as the folder syntax (no switches) is the same. Several other common toolkits sport rmdir commands as well. A workaround, if you do have an rmdir.exe executable in your path is to try using RD instead of RMDIR in your batch files. Of course if you do this you'll want to be sure you don't have an rd.exe anywhere in your path. -Noel

One additional thing... Are you sure you have your RMDIR command syntax correct? It might help to post a snippet of your batch file here for other eyes to review. -Noel

This happens to me as well. I am running a script inside a VMWare virtual machine, so it could be connected to the way the virtual machine handles I/O operations. But I think I have observed the same problem also outside the VMWare on Win7. And I believe I have only observed the problem when removing folder recursively (RMDIR /s). I do realize I used RMDIR instead of RD contrary to your recommendation... But believe me the same thing happens when I call RD. I am not aware of any GNU toolkit installed on my machine. I do miss the type command from unix right now... This simple sample script completes without complications most of the time. The problem seems to occur with higher probability when it is important that the RMDIR should complete. :) I can try to find a more reliable way to make this fail if this is not an acceptable sample. I know all this sounds a little crazy so just in case you refuse to believe me I've attached a snapshot. The amount of folders and files that need to be removed seems to contribute to the problem.

Here is another sample that fails a little more often. And I am more and more certain that this is a VMWare bug. I tried running the same script on a HDD and on a SSD outside VMWare on my Win7 host and didn't manage to provoke the problem. Not even once. If Rudy could confirm that he was running his script in a VMWare machine... we may have to go complain about this problem on a different forum. :P Kind regards, Alesh.

Hi Noel! I am glad I tickled your interest. :) Thanks for your research. I agree it is likely just a timing issue. But I was suspecting that either Windows Exploder or some other process is caressing these files while I was trying to delete them. I was particularly suspicious of Tortoise SVN, as I am manipulating source repositories with my batch. But I never suspected the blasted Windows Indexer. Never liked that thing really. Searching has gone to hell since WinXP. I do love my Win7... But I just hate that I have to pop open a shell and do a dir /s file_of_interest to find a file I am trying to find in a folder structure. Search never finds anything. I am of the opinion that the indexer is just a waste of CPU and HDD resources. :) I usually only let it index the start menu - otherwise I can't use the search function there. :/ Oh well... let's see if Win8 will deliver something more smart. I must say that the error message from RD is also rather cryptic. I mean it makes sense in retrospect. If one realizes that a folder or file could not be removed because it was in use... Then it makes sense. But an error message such as "Access denied" or "Could not delete file/folder in use..." would be more helpful. What I find curious is that I didn't get the error message from RD? Maybe the /Q switch killed it. Another mystery solved. Thanks Noel. Alesh.

Thanks for the excellent instructions. I have partially disabled Indexing myself but these do give some good extra insights. Actually I believe SVN repositories may be submitted to the TSVNCache.exe. So if you try to delete a folder that is a SVN repository and have Tortoise SVN installed it may be in use by TSVNCache. I think this is what is killing my script. Here are some instructions how to work around that: http://www.svntalk.com/node/3 Alesh.

Interesting, and I suppose not unexpected... The Tortoise SVN process of scanning the files to see if overlay icons need to be applied is certainly something that could temporarily latch onto folders. A third thing came to mind, though I don't think it would necessarily fail unless you actually had some image or other media files in the folder: Explorer makes thumbnails into Thumbs.db files and also a central database by reading files in the background. I'm not completely sure, but I believe the processes are actually separate, and the good news is that there's a group policy for disabling the Thumbs.db creation. · Click the Start orb · Enter gpedit.msc in the search box and hit Enter. · Expand User Configuration - Administrative Templates - Windows Components. · Click on Windows Explorer. · Right-click the entry "Turn off the caching of thumbnails in hidden thumbs.db files" and choose Edit. · Enable the setting. · Log off Windows and back on. -Noel

Thanks for the excellent instructions. I have partially disabled Indexing myself but these do give some good extra insights. Actually I believe SVN repositories may be submitted to the TSVNCache.exe. So if you try to delete a folder that is a SVN repository and have Tortoise SVN installed it may be in use by TSVNCache. I think this is what is killing my script. Here are some instructions how to work around that: http://www.svntalk.com/node/3 Alesh.

Interesting, and I suppose not unexpected... The Tortoise SVN process of scanning the files to see if overlay icons need to be applied is certainly something that could temporarily latch onto folders. A third thing came to mind, though I don't think it would necessarily fail unless you actually had some image or other media files in the folder: Explorer makes thumbnails into Thumbs.db files and also a central database by reading files in the background. I'm not completely sure, but I believe the processes are actually separate, and the good news is that there's a group policy for disabling the Thumbs.db creation. · Click the Start orb · Enter gpedit.msc in the search box and hit Enter. · Expand User Configuration - Administrative Templates - Windows Components. · Click on Windows Explorer. · Right-click the entry "Turn off the caching of thumbnails in hidden thumbs.db files" and choose Edit. · Enable the setting. · Log off Windows and back on. -Noel

This happens to me as well. I am running a script inside a VMWare virtual machine, so it could be connected to the way the virtual machine handles I/O operations. But I think I have observed the same problem also outside the VMWare on Win7. And I believe I have only observed the problem when removing folder recursively (RMDIR /s). I do realize I used RMDIR instead of RD contrary to your recommendation... But believe me the same thing happens when I call RD. I am not aware of any GNU toolkit installed on my machine. I do miss the type command from unix right now... This simple sample script completes without complications most of the time. The problem seems to occur with higher probability when it is important that the RMDIR should complete. :) I can try to find a more reliable way to make this fail if this is not an acceptable sample. I know all this sounds a little crazy so just in case you refuse to believe me I've attached a snapshot. The amount of folders and files that need to be removed seems to contribute to the problem.

Here is another sample that fails a little more often. And I am more and more certain that this is a VMWare bug. I tried running the same script on a HDD and on a SSD outside VMWare on my Win7 host and didn't manage to provoke the problem. Not even once. If Rudy could confirm that he was running his script in a VMWare machine... we may have to go complain about this problem on a different forum. :P Kind regards, Alesh.

I created a batch file like yours (but with @ECHO OFF) and ran it in a VMware Windows 7 x64 VM from a similar folder and was able to reproduce the problem in about 1 in 50 loops, along with a bit more info in the form of an error message apparently from RMDIR. Note the bold text: C:\Users\NoelC\Documents\Work>rmdir_test 88 File(s) copied All gone. 88 File(s) copied The directory is not empty. Still there. A subdirectory or file test_fldr already exists. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. 88 File(s) copied All gone. Terminate batch job (Y/N)? y Also, like you, I could not capture a failure on my host Windows 7 x64 system. What was left when the RMDIR failed were only one or two subfolders, e.g., C:\Users\NoelC\Documents\Work\test_fldr\PCAT I wonder if indexing might have something to do with this. Indexing is shut off on my host system, while it is on in my VM. I'm going to try shutting it off then retesting. -Noel

OK, I've specifically disabled indexing and lo and behold, with no other changes, the rmdir_test batch file in the VM has now runs through many thousands of iterations without once failing to remove the folder. Taking it one step further, I re-enabled indexing in the VM, rebooted, and boom, now the batch file catches an RMDIR failure again. I don't see any reason to think this has to be specific to a virtual machine, either. It may just have to do with the timing of the file system being different. This is yet ANOTHER good example showing indexing is intrusive and why it should be disabled! -Noel

Hi Noel! I am glad I tickled your interest. :) Thanks for your research. I agree it is likely just a timing issue. But I was suspecting that either Windows Exploder or some other process is caressing these files while I was trying to delete them. I was particularly suspicious of Tortoise SVN, as I am manipulating source repositories with my batch. But I never suspected the blasted Windows Indexer. Never liked that thing really. Searching has gone to hell since WinXP. I do love my Win7... But I just hate that I have to pop open a shell and do a dir /s file_of_interest to find a file I am trying to find in a folder structure. Search never finds anything. I am of the opinion that the indexer is just a waste of CPU and HDD resources. :) I usually only let it index the start menu - otherwise I can't use the search function there. :/ Oh well... let's see if Win8 will deliver something more smart. I must say that the error message from RD is also rather cryptic. I mean it makes sense in retrospect. If one realizes that a folder or file could not be removed because it was in use... Then it makes sense. But an error message such as "Access denied" or "Could not delete file/folder in use..." would be more helpful. What I find curious is that I didn't get the error message from RD? Maybe the /Q switch killed it. Another mystery solved. Thanks Noel. Alesh.

Here's a full rundown on what I know about Windows Search and indexing, and how to disable indexing yet retain all the useful parts of Windows Search (such as the ability to search the Start Menu): About Windows Search & Disabling Indexing Indexing is supposed to make it quick and easy to find things on your computer using Windows Search (that little box at the upper-right of the Windows Explorer application). But when you think about it, does it make sense to read all the files on your disk, extract everything you could possibly want to search for, and store it on that same disk another way? To even consider indexing providing better performance than just searching the files, Microsoft must be picking and choosing the data they think you'll want to look for (excluding data you WON'T want to search for), where you'll want to search, and in what kinds of files, and in fact they are. How could they know everything you'll ever want to search for? They can't. Not everything is indexed, and never will be! Try this: Create a simple text file on your disk, in a temporary folder. Call it "FindMe.log" and put in the text "This file contains important tax information". Now navigate to that folder with Explorer and enter the word "tax" into the Search box at the upper-right. Enter any of the words in that file! Windows Search will not find the file, because it simply does not LOOK in .log files by default, and there's no fallback strategy - Windows Search simply does not index nor search for information for some kinds of files. Incredible! All it takes is ONE TIME searching for something you know is there and NOT finding it to destroy your confidence in Windows Search. And so they scan through your files endlessly, pick out the strings you might someday search for, and store them in yet another set of files (the "index"). As though your computer has nothing better to do. Not only is the basic premise of this wrong, but it's not even implemented very well. The index often becomes corrupted, and so Microsoft has provided functions for you to clear and regenerate it. Just what you wanted to be doing - NOT. Consider these shortcomings: Only strings Microsoft thinks you'll search for are indexed. Some file types are simply not indexed or searched by default – e.g., .log files, and there's no fallback. If you create a new file type no one's seen before, its contents will not be indexed. Because of poor implementation, indexing will miss things in some file types that are indexed – e.g., older Microsoft Word documents or files using Unicode (Microsoft's own invention). Indexes often become corrupted and the Windows Search results fall out of date or it stops finding things entirely. Indexing uses computer time and increases disk wear. Indexing can interfere with file operations, causing your system to report disk corruption (search the web for "Atomic Oplock") or to fail on simple operations such as removing folders. In summary, indexed Windows Search operations in Windows 7 are intrusive and can't be trusted to find your data in your files when it's critical. Searching for filenames on the disk using Windows Search actually can be useful (though the syntax to ensure it searches only filenames is a bit tricky), but this doesn't require indexing. Knowing these things, you may wish to disable indexing. This won't stop you being able to use Windows Search - on the contrary with indexing turned off Windows 7 will actually search your actual files (within the limitations listed above) just when you tell it to, and (since indexing isn't implemented very well) it can actually INCREASE the probability that you will find what you're looking for. Do all the following: Disable the indexing service: 1. Click Start and type the word services in the search box. 2. When Services (with little gears) comes up, click it. 3. Scroll down to the Windows Search service. 4. Right click it and choose Properties. 5. Change the Startup type to Disabled. 6. Click [ Stop ] to stop the service. Delete the existing index: 1. Click Start and type the word index in the search box. 2. When Indexing options comes up, click it. 3. Click the [ Advanced ] button. 4. Click the [ Rebuild ] button to delete the index. So that you're not nagged by Windows to reenable indexing: 1. Click Start and type folder options in the search box. 2. In the Folder Options dialog, click the Search tab. 3. Enable setting "Don't use the index when searching in file folders for system files (searches might take longer)". Ensure Library features don't try to use Indexing: 1. Click Start and type group policy into the search box. ** 2. In the Local Group Policy Editor, navigate to User Configuration – Administrative Templates – Windows Components – Windows Explorer. 3. Enable setting Turn off Windows Libraries features that rely on indexed file data. ** If you do not have the Group Policy Editor, instead of the above steps 1 - 3 make a new DWORD value in your registry: [HKCU\Software\Policies\Microsoft\Windows\Explorer] DisableIndexedLibraryExperience = 0x00000001 To ensure you can search in the Start Menu: 1. Right click on the Start orb and choose Properties. 2. Click the [Customize...] button at the upper-right. 3. Scroll down to Search other files and libraries and choose the Search with public folders option. Reboot after completing all of the above. -Noel

On Win7 x64, I seem to have luck calling RMDIR or RD through a CMD /c instance. CMD starts a new command prompt instance and /c indicates "Carries out the command specified by string and then terminates", ie. you can give it the RMDIR command and it will return to the batch file after completion. Not sure what happens behind the scenes, but that solved the problem for me. Plus you get to keep your indexing ;) So instead of using RMDIR /s /q xxxx, simply try: CMD /c RMDIR /s /q xxxx For example: IF EXIST %1 CMD /c RMDIR /s /q %1

Plus you get to keep your indexing ;) Why would you want to? I don't think anyone's ever detected much of anything good that comes from it. -Noel Detailed how-to in my eBooks: Configure The Windows 7 "To Work" Options Configure The Windows 8 "To Work" Options

I read your previous comment about indexing, and I would agree that content indexing is rather useless. Unfortunately, disabling indexing also disables filename indexing. Windows Libraries is perhaps an under appreciated feature... 95% of searches tend to be around the same subset of folders (archives, code, documents, backups, music, downloads, etc.), and libraries are a convenient way to tell the OS which folders you're most interested in. With indexing enabled, doing a search in the start menu or libraries for the word "studio" gives me ~200 results under a second, most results being relevant to my interests. Without indexing it takes well over 2 minutes (I stopped it) to find 200 files across multiple terabytes of harddrives, and quite a bit are from places I wasn't looking for (eg. Program Files). Really, that's unacceptable. File systems are very poor at lookup performance - indexed databases exist for a reason! Windows Indexing, while not perfect, is certainly a step in the right direction and works rather well since Win7.