|Pathologically Eclectic Rubbish Lister|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
This sounds like the classic "in-use" problem. Even if the process doing the deletion doesn't have the directory to be deleted as one of it current directories-- every process has a current directory for each logical drive visible to it!--if any other process in the system is using that directory, directly or indirectly, then permission to delete that directory will be denied.
As a simple example: Say you have a system with 2 drive C: & D:, the directory your trying to delete is d:\foo. You have a shell window running, and at some point you switch to the d: drive and cd to \foo....then you switch back to the c: to run the script to delete d:\foo. You get permission denied.
Even though you are running the script at the C:\perl prompt, that shell session still has a handle to d:\foo, and so the system won't let you delete it. Right or wrong, that is the way the system works, and you have to work within that constraint.
The one that usually catches me out is when I have edited a file in the target directory tree and even though I have closed the file, the file dialog retains the last directory I visited as the default location for the next time I want to open a file. So, even though I have no file open in that directory, the file dialog retains a handle to it, and I am prevented from deleting it until I either close the editor, or bring up the file dialog and switch to a different directory.
The really horrible bit is that there are many file dialogs in the system, and each retains it's own sense of the CWD. It can be a real pain working out what and where the open handle is being retained.
I'm sorry, but I don't have a solution to this, just a logical (if neither official nor what you want to hear) explanantion.
The explorer seems to have some special logic built in so that if you right-click delete a subtree, the root directory of that subtree, which you made a CWD when you highlighted it, doesn't disappear until you move to another location, and it then is deleted. Something similar to the unix "mark for deletion" process. Unfortunately, this seems to a be a property of the explorer, rather than the underlying OS, and worse, even the explorer doesn't seem to be able to get it right all the time.
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
In reply to Re: Re: Re: rmtree deletes everything inside the folder but doesn't deletes the root folder him self