FileMove() Limitation

[michaelslamet]

This is taken from FileMove() helpfile:

Remarks

If the source and destination paths are on different volumes a copy and delete operation is performed rather than a move.

This code will return "FailMove Successed" if it run from drive C:

It will return "FileMove Failed" if run from another drive letter (eg: run from drive D: or network share)

If FileMove(@ScriptFullPath, "c:\") then
    MsgBox(0,"Info","FailMove Successed")
Else
    MsgBox(0,"Info","FileMove Failed")
EndIf

 

Why not use external command "move" ?

Because I need the return code with something like

If FileMove($old_file, $new_file) Then

 

Is there any workaround for this? Maybe improvement of FileMove() function?

[MHz]

@ScriptFullPath will have a handle open on it while running i.e File in use remember. Without checking, I would expect that a limitation is placed so that a actual move from one drive partition to another drive partition is not allowed due to the handle being open. When you do a FileMove on the same drive partition then you are just doing a rename. The later does not actually move the physical file on the drive partition.

Edit: Changed a word

Edited August 3, 2013 by MHz

[michaelslamet]

Thanks MHz

That is make sense. So the only solution for this is make sure it move to the same drive?

I just realized that move (internal command) also have a same behaviour with FileMove() so I cant use move

[MHz]

Yes, same drive partition. A possibility may exist for a symlink. I am not sure if a symlink targeting your script can be changed while running. That could be another option so you can update the symlink to another target file elsewhere. Symlinks can point to other drives including network paths. That may be worth testing.

[michaelslamet]

Ah, yes, same drive partition, not only same drive, but it should be same partition.

Noted about symlink, I will searching more information about it.

Thanks a lot, MHz

[MHz]

Moving files between drive partitions on the same physical drive is the same as moving a files to another drive partition. This is why I referred to "drive partition" as to make certain that the meaning was not being lost. A drive partition has its own independent filesystem.

Cheers

Edit: Strike a word that may cause confusion with using drive partition

Edited August 3, 2013 by MHz

[michaelslamet]

Why FileMove() can not do this while dos internal command "move" can?

my_file.exe is currently running

$source = "\\my_server\my_share\my_folder_A\my_file.exe"
$target = "\\my_server\my_share\my_folder_B\my_file.exe"
FileMove($source, target, 1)

 

File doesn't moved, EXCEPT my_server_my_share is mapped as some drive letter.

File sucessfully moved using "move" command:

move my_servermy_sharemy_folder_Amy_file.exe my_servermy_sharemy_folder_Bmy_file.exe

FileMove() limitation?

[MHz]

Moving a running file source to another folder parallel to the current folder.

Move does do it well. Expected behavior.

FileMove does a copy into the destination folder and leaves the source even after closing the process. This is unexpected behavior.

Moving a running file source to rename in same folder.

Move succeeds. Expected behavior.

FileMove succeeds. Expected behavior.

Tested on a Western Digital NAS with EXT3 filesystem and using Windows 7 Pro on the PC. AutoIt 3.3.8.1

So when you say that it does not move, is it similar to my unexpected behavior that is underlined above? I get a copy and not a move with FileMove.

$source = "\\STORAGE\Public\a\test.exe"
$destination = "\\STORAGE\Public\b\test.exe" ; to another folder
;~ $destination = "\\STORAGE\Public\a\test1.exe" ; in same folder
FileMove($source, $destination, 1)

Using similar code to yours.

Edit: added code

Edited August 3, 2013 by MHz

[michaelslamet]

Seems like my brain is getting old

All I remember is the conclusion is FileMove not working on network share if not mapped

I cant test it now because I have no network at home, but I'm going to test it ASAP

Could you please test: does FileMove work if you map the storagepublic share?

My NAS running FreeBSD with it's native filesystem (I forgot what it is), test PC is Win7 and AutoIT 3.3.8.1

[MHz]

Tested this as successful

If DriveMapAdd('Z:', '\\STORAGE\Public') Then
    $source = 'Z:\a\test.exe'
    $destination = 'Z:\b\test.exe'
    FileMove($source, $destination, 1)
    DriveMapDel('Z:')
EndIf

It also worked on a manual mapping without using DriveMap* functions.

[michaelslamet]

Tested this as successful

If DriveMapAdd('Z:', '\\STORAGE\Public') Then
    $source = 'Z:\a\test.exe'
    $destination = 'Z:\b\test.exe'
    FileMove($source, $destination, 1)
    DriveMapDel('Z:')
EndIf

It also worked on a manual mapping without using DriveMap* functions.

 

Yes, same with my test

My test is using manual mapping without DriveMapAdd function

So, this is a FileMove() bug?

[MHz]

I find that DriveMap* functions have no effect to cause failure on my test environment. The use of FileMove is consistent on UNC path or DriveMap path. I even tried UNC while DriveMap*ed and does the same.

The issue that I detected was the unexpected behavior in >post #8

Bug? FileMove does not do as well as Move in the same environment setup which leads to stating that a possible issue exists.

Edited August 3, 2013 by MHz

[MHz]

Yes, same with my test

My test is using manual mapping without DriveMapAdd function

So, this is a FileMove() bug?

When you map your share to a drive letter as current user, are you running your script as current user or admin?

As I do get failure as to running the test script as admin on a manual mapped drive.

If mapped as current user and running script as admin then failure happens. AFAIK, you need to map a drive in the same user environment as the script.