DirRemove only removes the content of the directory

[meisandy]

Hi,

I need your help with some file management please!

I've created a window that creates two files in a folder simply by DirCreate and FileOpen on mode 2

The window then display the contents of the two files

...working fine...

I then need to delete the folder and everything in it, but this is where the problem lays.

I'm using DirRemove with mode 1[DOSTreeComand] when I've removed the thingy that displays the contents, so I'm fairly positive nothing else is using it but still all that it does is delete the two files inside and not the actual folder/directory?

P.S I'm running it as Admin as I've added '#RequireAdmin'

Any help/idea's please?

Edited July 20, 2010 by DjATUit

[czardas]

Is the folder read only? (Edit: Hmm, I guess not). Are you sure it's not being used? Can we see your code?

Edited July 20, 2010 by czardas

[meisandy]

Well to be honest the first post was a brief description and the code is quite complex, plus I'm not at liberty to show the whole code but I can show you what I believe to be suitable!

So here is a snippet of the directory and file creation that happens once all errors have been tested for:

DirCreate(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname))
                    FileOpen(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/txtlist.lyt", 2)
                    FileOpen(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/wordlist.lyt", 2)
                    FileClose(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/wordlist.lyt")
                    FileClose(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/txtlist.lyt")

And the code I've divised to supposidly delete the created directory and files:

_GUICtrlListView_Destroy($List_maindb)
            _GUICtrlListView_Destroy($List_TxtList)
            MsgBox(0, "", IniRead($INI_File, "Databases", "Kept", "databases") & "\" & $CRRF)
            FileDelete(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & $CRRF & "\txtlist.lyt")
            FileDelete(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & $CRRF & "\wordlist.lyt")
            $RD = DirRemove(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & $CRRF, 1)
            $DatabaseFiles = _FileListToArray(IniRead($INI_File, "Databases", "Kept", "databases") & "\")
            If $RD = 0 Then MsgBox(0, "", "Directory doesn't exist")
            $List_maindb = _GUICtrlListView_Create($Window_Databases, "Databases", 15, 25, 150, 480, BitOR($LVS_SHOWSELALWAYS, $LVS_REPORT))
            _GUICtrlListView_SetColumnWidth($List_maindb, 0, 140)
            For $dbs = 1 To UBound($DatabaseFiles) - 1
                _GUICtrlListView_AddItem($List_maindb, $DatabaseFiles[$dbs])
            Next

[czardas]

Hmm, I can see it's slightly complicated with the GUI. I suggest you try to simplify it by trying to solve it for 1 file, and then add more. Unfortunately I don't have so much time right now. You don't need to delete each individual file, because removing the directory should do that for you. I'm not sure what the problem is, but this simple code does what I expect it to do. Why does your code not delete the directory and mine does? Perhaps someone else can figure it out.

; Test to deletion.

DirCreate(@ScriptDir & "\DIR")
$hFile = FileOpen("DIR\myTest.txt", 2)
Sleep(2000)
FileClose($hFile)
DirRemove(@ScriptDir & "\DIR", 1)

[MvGulik]

I'm using DirRemove with mode 1[DOSTreeComand] when I've removed the thingy that displays the contents, so I'm fairly positive nothing else is using it but still all that it does is delete the two files inside and not the actual folder/directory?

Generally a sign that that folder is still actively used by some process.

- check the current working folder just before the DirRemove() use.

(don't know if AutoIt maintains active folders for only one (the currently used/active) drive or also for other drives. In case your working folder point to a different drive.)

---

Don't seems to matter in AutoIt's case.

Global $result
DirCreate(@ScriptDir & "\TMP_DIR")
FileChangeDir(@ScriptDir & "\TMP_DIR")
DebugOut('@WorkingDir', @WorkingDir) ;### Debug DebugOut.
MsgBox(0,'MsgBox','MsgBox') ;; to select target folder, no effect, will not block delete of folder.
$result = DirRemove(@ScriptDir & "\TMP_DIR", 1)
DebugOut('$result', $result) ;### Debug DebugOut.
DebugOut('@WorkingDir', @WorkingDir) ;### Debug DebugOut.

@WorkingDir = "C:\CODE\AutoIt3\Examples\Helpfile\TMP_DIR" {St} [0,0]
$result = 1 {I3} (0x00.00.00.01) [0,0]
@WorkingDir = "C:\CODE\AutoIt3\Examples\Helpfile" {St} [0,0]

---

Get some system tool to check what process is locking that folder.

If its you script ...

Edited July 20, 2010 by MvGulik

[meisandy]

I've tried the top code in your post, MvGulik and it worked fine on a completey different script but when I tried to implement it into mine it didn't do anything to help!

I noticed that the files inside the folder delete on exit, so I tried registring a function to delete the directory on exit, but that failed

So i'll look for something to help me get to the cause of the problem

Meanwhile, please still suggest things to me!

[MvGulik]

I've tried the top code in your post, MvGulik and it worked fine on a completey different script but when I tried to implement it into mine it didn't do anything to help!

It was not intended to be implemented into any other script. Its was just to proof that the current @working setting in AutoIt can't be it. (which was my initial assumption to be the source of your problem.)

... hum ... after looking again at the code you posted.

I suggest you read up on how to use FileOpen and FileClose in relation to file-handles before anything else. (If you coded that, that is.)

FileOpen(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/txtlist.lyt", 2)
FileOpen(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/wordlist.lyt", 2)
FileClose(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/wordlist.lyt")
FileClose(IniRead($INI_File, "Databases", "Kept", "databases") & "\" & GUICtrlRead($Input_NewDBname) & "/txtlist.lyt")

[meisandy]

Okay...sorry you must of misunderstud me, it isn't the two files at fault, its the directory - which I've looked at using a tool called Unlocker which shows any process using the folder/file and the only process was the program itself!

And anyway, I'm happy with the way the two files delete but interestingly I also looked at them using Unlocker and found that two processes belonging to the program/autoit are using them when deletion take place (I don't know weather it would be a message box I put in there or not)?!

[MvGulik]

Okay...sorry you must of misunderstud me, it isn't the two files at fault, its the directory - which I've looked at using a tool called Unlocker which shows any process using the folder/file and the only process was the program itself!

And anyway, I'm happy with the way the two files delete but interestingly I also looked at them using Unlocker and found that two processes belonging to the program/autoit are using them when deletion take place (I don't know weather it would be a message box I put in there or not)?!

- misunderstud me: Always possible. (On both sides of course.)

- its the directory: Thats the final problem. The target is to find the source of this behavior.

- Unlocker ... only process was the program itself: Good. Elimination of a possible other source for the problem.

- two processes belonging to the program/autoit are using them when deletion take place.

I'm not to sure about what your revering to here. The only thing that comes to mind here is the fact that the code you showed is opening two files. And that the closing command that is used to close those files is(ok: seems) ... flawed -> there (probably) not closed.

If you want to be sure that those files are not the reason for the DirRemove() failure. Temporary disable all related code to those files (open, read/write, close). And see if the DirRemove() still fails. If not ... source found. If yes ... I'm out of idea's.

Edited July 21, 2010 by MvGulik

[meisandy]

Okay, I've kind of given up on the method I'm using and by process of elimination and common sense I've devised another method which seems to be working!

But thank loads anyway MvGulik!