Weve used robocopy in place of move on windows before (windows is pretty painful)
Are you sure it is definitely failing? If I remember correctly robocopy would return an os error when invoked from kdb+ but would do what we had asked it to do successfully. I assume it was returning a non 0 exit code which kdb+ is then propagating. Our solution was just ignore os errors from robocopy commands!
Yea I do see `os err but its definitely not moving the requested folders. It seems the issue is only happening when I try and move folders across different drives. If I keep drive the same it works fine. I was trying to edit .os.ren in aquaq but can’t get robocopy to work at all from q.
I think I have a workaround for now to keep drive the same, its not ideal, but works.
To explain this a little, this is essentially invoking the windows command interpreter with the /c argument to supply a command to be executed immediately. In other words, it’s running robocopy from within a child cmd.exe process, where it appears to work fine
Hope that helps
Jonathon
From:personal-kdbplus@googlegroups.com <personal-kdbplus@googlegroups.com> on behalf of Roni Hoffman <hoffmanroni@gmail.com> Sent: 17 January 2018 20:50:43 To: Kdb+ Personal Developers Subject: Re: [personal kdb+] Windows system move vs robocopy
Thanks Johnny,
Yea I do see `os err but its definitely not moving the requested folders. It seems the issue is only happening when I try and move folders across different drives. If I keep drive the same it works fine. I was trying to edit .os.ren in aquaq but can’t get robocopy to work at all from q.
I think I have a workaround for now to keep drive the same, its not ideal, but works.
ROBOCOPY has some `interesting’ error codes when it finds part of the target file already existing, which causes bogus 'os errors even when it completes successfully. Below is a simple wrapper that I frequently use to overcome this issue while logging what actually happened: https://github.com/FlyingOE/q_Wind/blob/master/ROBOCOPY.CMD