michaelslamet Posted August 3, 2013 Share Posted August 3, 2013 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? Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 (edited) @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 Link to comment Share on other sites More sharing options...
michaelslamet Posted August 3, 2013 Author Share Posted August 3, 2013 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 Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 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. Link to comment Share on other sites More sharing options...
michaelslamet Posted August 3, 2013 Author Share Posted August 3, 2013 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 Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 (edited) 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 Link to comment Share on other sites More sharing options...
michaelslamet Posted August 3, 2013 Author Share Posted August 3, 2013 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? Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 (edited) 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 Link to comment Share on other sites More sharing options...
michaelslamet Posted August 3, 2013 Author Share Posted August 3, 2013 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 Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 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. Link to comment Share on other sites More sharing options...
michaelslamet Posted August 3, 2013 Author Share Posted August 3, 2013 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? Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 (edited) 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 Link to comment Share on other sites More sharing options...
MHz Posted August 3, 2013 Share Posted August 3, 2013 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now