Why does RMDir /r fail to delete folder?

I am either getting senile or stupider by the moment, or both. For the life of me, I can't figure out why the following doesn't succeed:

SetOutPath $DESKTOP ; deflect current working directory from RMDir target
RMDir /r '"C:\Documents and Settings\Admin\Application Data\My App"'

True, "C:\Documents and Settings\Admin\Application Data\My App" is not empty, but I thought that's what /r is for.

What others reason could explain that?

(I am using NSIS 2.45 on Windows XP SP3.)

Try FileMon or Process Monitor and see what the error is...

Thanks! I just tried FileMon and the only failure reported is:

1:51:24 PM svchost.exe:1052 OPEN C:\WINDOWS\Prefetch\CLEANMYAPPDIR-SETUP.EXE-0E4B9029.pf FILE NOT FOUND Options: Open Access: All

I am trying to use 'RMDir /r' in an install section and this is where it fails.

Same exact instructions in '-un.post' section succeed.

Could that be related?
If so, how?

Interesting. When I replace

RMDir /r '"C:\Documents and Settings\Admin\Application Data\My App"' 

With:

  ReadEnvStr $varCOMSPEC COMSPEC

  nsExec::Exec '"$varCOMSPEC" /C rmdir /Q /S "C:\Documents and Settings\Admin\Application Data\My App"'

It works.

This is baffling.

There has to be more filemon output than just the prefetch line, your filter could be wrong, try just *. But, I'm guessing your problem is actually the quotes, just use RMDir /R "c:\path", you don't need to pack the double quotes in single quotes...

Anders, you are king. You were right in both:

1. The single quotes posed a problem (I tried without them before, but being confused I panicked, added them and forgot to removed them).

2. The FileMon filter that I specified didn't take into account the truncation of the process name and so it filtered too much.

It turns out that there was a process running in that folder that I was trying to delete. The nsExec version succeeded because I took care of existing the process beforehand. Once I did the same for NSIS's RmDir and used only one set of quotes, the operation succeeded.

Thank you Anders!

For future reference, when you execute something you should pack the whole command line in single quotes with the application (and any other path that can contain spaces in double quotes): '"c:\some path\myapp.exe" /param' and you do this because of the "c:\Program.exe" vs "c:\Program Files\foo.exe" problem (Get this wrong and "c:\Program.exe" gets executed with "Files\foo.exe" as its parameter, this is also a security problem)

Instructions that only take a single path don't have this problem...