DirMove flag=1 recoursing if dst. already exists - why?

[orbs]

from the DirMove help file:

 

If the destination already exists and the overwrite flag is specified then the source directory will be moved inside the destination

 

in what scenario would anyone find it useful? or is it a necessary evil, due to Windows internal conditions? i'd expect that if the overwrite flag is specified, then DirMove would... well... overwrite the destination, not recourse into it.

what kind of programming logic am i missing here?

[JohnOne]

I think the logic is that the developer should test if the dest dir exists before trying to move another to it's place and deal with that accordingly.

But id the developer does not, then AutoIt will offer some default behaviour and what you describe might be the least destructive.

Of course I'm only surmising.

[orbs]

that is very untypical to AutoIt functionality, which in any other case grants the developer much credit from the very beginning - i'm referring to the very loose nature of declaration of variables and their types (or lack thereof).

anyway, a developer who specifies the overwrite flag - it is not the default - is supposed to know what he is doing, and he expects just that.

do surmise on...

[JohnOne]

I've got nothing.

It is odd and behaviour.

[Mat]

I think "inside" is a little too vague here. I'll try and clarify the behaviour here.

With the following initial directory structure:

C:\Foo
-> HelloFoo.txt
C:\Bar
-> HelloBar.txt

Using DirMove(Foo, Bar, 1) will result in:

C:\Bar
-> Foo
-> -> HelloFoo.txt
-> HelloBar.txt

This literally is "Move the directory 'Foo' to the directory 'Bar'", which is sort of logical.

The inconsistency is that DirCopy will instead merge the folders. 

This makes it impossible to move the contents of a folder into another.

Whether this is what it should be I don't know, but the behaviour makes sense to me.

[JohnOne]

To me it does seem a little odd, I'd expect to work as FileMove does.

DirRemove is equally as baffling with it's default flag of 0 " 0 = (default) do not remove files and sub-directories"

How do you remove a dir without removing it's subdirs and files?

[Mat]

To me it does seem a little odd, I'd expect to work as FileMove does.

DirRemove is equally as baffling with it's default flag of 0 " 0 = (default) do not remove files and sub-directories"

How do you remove a dir without removing it's subdirs and files?

This is normal behaviour. If you try and delete a folder you might see a message like "This folder is not empty, are you sure you want to delete it?" (I can't remember what it says as I disabled it long ago).

[JohnOne]

Never mind, I was looking at old 3.3.8.1 help file, it's been worded properly now.

"0 = (default) deletes the folder, only if it is empty"

[Richard Robertson]

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488%28v=vs.85%29.aspx

The Windows API specifies that the directory must be empty. This is the most likely reason AutoIt uses that by default.

[orbs]

Using DirMove(Foo, Bar, 1) will result in:

C:\Bar
-> Foo
-> -> HelloFoo.txt
-> HelloBar.txt

This literally is "Move the directory 'Foo' to the directory 'Bar'", which is sort of logical.

 

specify the overwrite flag makes you conclusion insensible, because if you intent to move a folder INSIDE another folder, no overwrite can possibly happen.

perhaps it's just the flag should not be labeled "overwrite" but "move inside". that fits the actual operation better. also note that if you do not set the "overwrite" flag, the operation fails.

 

The inconsistency is that DirCopy will instead merge the folders. 

This makes it impossible to move the contents of a folder into another.

 

I too expected the same behavior as DirCopy, i.e. move files from Foo to Bar and overwrite files as needed. that makes a lot more sense to me.

[czardas]

specify the overwrite flag makes you conclusion insensible, because if you intent to move a folder INSIDE another folder, no overwrite can possibly happen.

 

If the target folder already contains a folder with the same name as the migrating folder, overwriting can occur.

Edited May 14, 2014 by czardas

[orbs]

If the target folder already contains a folder with the same name as the migrating folder, overwriting can occur.

 

no. the source folder will be moved inside the subfolder.of the destination. try this:

DirCreate('C:\TEMP\src')
FileWrite('C:\TEMP\src\file.txt','src')
DirCreate('C:\TEMP\dst\src')
FileWrite('C:\TEMP\dst\src\file.txt','dst')
DirMove('C:\TEMP\src','C:\TEMP\dst',1)

you'd think that the file with the string "src" will overwrite the file with the string "dst", right?

well, this is the result:

C:TEMPdst>dir /s /b

C:TEMPdstsrc

C:TEMPdstsrcfile.txt

C:TEMPdstsrcsrc

C:TEMPdstsrcsrcfile.txt

[MHz]

Try this example to show overwrite and merging. It creates dir0 and dir1 in current directory and moves dir1 into the structure of dir0. Msgbox shows contents of 0.txt changing.

expandcollapse popup

; cleanup from previous test run
If DirRemove('dir0', 1) Then
    Sleep(500)
EndIf

; create dir structure for testing
If DirCreate('dir0\dir1') Then
    For $1 = 1 To 4
        ; create dir structure to be moved
        _DirCreate1()
        ; move dir
        If DirMove('dir1', 'dir0', 1) Then
            ; output tree structure of folders and files
            _DirTree()
            ; read a common text file
            MsgBox(0, '0.txt', FileRead('dir0\dir1\dir1\0.txt'), 1)
        EndIf
    Next
EndIf

Exit

Func _DirCreate1()
    Local Static $data = 0
    If DirCreate('dir1') Then
        $data += 1
        ConsoleWrite('created dir1' & @CRLF)
        If FileWrite('dir1\0.txt', $data & @CRLF) Then
            FileWrite('dir1\' & $data & '.txt', $data & @CRLF)
            ConsoleWrite('created text files in dir1' & @CRLF)
        Else
            ConsoleWriteError('failed to create text files in dir1' & @CRLF)
        EndIf
    Else
        ConsoleWriteError('failed to create dir1' & @CRLF)
    EndIf
EndFunc

Func _DirTree()
    Local $out, $pid
    $pid = Run('cmd /c tree dir0 /f /a', '', Default, 8)
    If @error Then Return 0
    Do
        Sleep(10)
        $out &= StdOutRead($pid)
    Until @error
    ConsoleWrite('cmd /c tree dir0 /f /a' & @CRLF)
    $out = StringLower(StringStripWS($out, 3))
    ConsoleWrite($out & @CRLF & @CRLF)
EndFunc

And the output is

expandcollapse popup

created dir1
created text files in dir1
cmd /c tree dir0 /f /a
folder path listing for volume system
volume serial number is <removed>
c:\temp\dirmove\dir0
\---dir1
    \---dir1
            0.txt
            1.txt

created dir1
created text files in dir1
cmd /c tree dir0 /f /a
folder path listing for volume system
volume serial number is <removed>
c:\temp\dirmove\dir0
\---dir1
    \---dir1
            0.txt
            1.txt
            2.txt

created dir1
created text files in dir1
cmd /c tree dir0 /f /a
folder path listing for volume system
volume serial number is <removed>
c:\temp\dirmove\dir0
\---dir1
    \---dir1
            0.txt
            1.txt
            2.txt
            3.txt

created dir1
created text files in dir1
cmd /c tree dir0 /f /a
folder path listing for volume system
volume serial number is <removed>
c:\temp\dirmove\dir0
\---dir1
    \---dir1
            0.txt
            1.txt
            2.txt
            3.txt
            4.txt

0.txt is overwritten with each loop. 1.txt, 2.txt, 3.txt and 4.txt shows merging into the same folder. Not a sane operation at all as it varies depending on certain conditions.

[czardas]

no. the source folder will be moved inside the subfolder.of the destination. try this:

 

It was default Windows behavior I was referring to. I admit I wasn't aware of this AutoIt behavior - dumping a new folder inside the root directory. MHz's example illustrates what I am talking about. If I wasn't in the middle of migrating to a new OS, I would be able to test the code.

I have been merging a lot of folders recently whilst removing duplicate files. I simply renamed files and made sure overwriting was disallowed. I didn't use DirMove(), otherwise I would have discovered this.