I want to copy files using Put Directory from host to target recursive.
Doing this the test fail with OS:Error. I already know what the error is but want to know “why”?
Maybe “Put Directory” need to have a “patch?”
So the Problem is, that during the copying one file lets call it “_server” is copied from host to target and this file already exists there. So this file needs to be overwritten by “Put Directory”.
BUT in addition “_server” is not only a “file” on the target but is a running process. So if i do “systemctl status _server” i see that my process is running and the file “_server” on the target is in the same location i want to put my files into.
Now my solution is to use “Execute Command systemctl stop _server” first (to stop the process on target) and then do the “Put Directory”. Now everything works fine. No errors anymore.
So it seems that if i use “Put Directory” and some of the file which is transferred to the target is “under use” or “running process” the “Put Directory” fails to copy the file. But why?
I tried to copy exactly the same files using WinSCP. And surprisingly WinSCP had NO Problem to copy the file “_server” to target even if i have NOT stopped the service beforehand.
For this i used WinSCP 5.21.1 (quite old version from 24.06.2022)
And i need to use “Put Directory” because i have subdirs i want to copy not only files.
I would argue that this is working exactly as it should, also it’s not likely something that can be changed in the robot framework library as it’s controlled at the operating system.
The whole point of an application taking an operating system lock on a file that’s in use is to prevent other processes modify it while it’s in use as this can cause data loss and even file corruption.
In this respect windows tends to not follow the standards properly in some cases, and this is one of the reasons windows is more prone to stability issues and viruses.
Stop the process, copy the files, restart the process is the correct procedure especially when binaries are involved, the way you did it with WinSCP is likely to cause you issues down the track, and the very lats thing you want is the testing automation to be blamed for a bug as it will be constantly brought up by the developers.
Another way to approach the issue if you can is to put the executable and data files in different folders so when you do Put Directory it’s only files that are not locked that get pushed.
Another way would be to use Put File rather than Put Directory and use wildcard match on the files to put so you can make sure the locked files are not pushed to the server.
thank you for your reply - and i agree with you.
As i reboot my device after copying the files over anyway i thought that i don’t really need to stop the service first and as copying the files using WinSCP without stopping the process works i thought i can do the same with RF.
But - well - i’m fine with that “extra” step. It’s not a big deal to stop the service - just one more command
Add a keyword that runs the stop command and add it before the keyword that does the copy. If you do this, then there should be no need for a reboot just add another keyword with the start command after the copy, then it won’t be an extra step, just run the robot file and you save time not needing a reboot.
i need to reboot my device after the copying anyways - so its fine for me.
During my Put Directory i copy files and sub directories from host to my target and after that i have to do a reboot.
I copy configuration files and other stuff - and one file is a binary which is in use on my target that’s why i have to stop the service. After that i do a reboot.
