Hi, have a script at work that copies packages and scripts to computers at work when they start up. However I’ve suddenly started to get the error below. I’m wondering if its to do with maybe how an updated dynamo saves files. It could be related to my new computer but IT says its the same as my old one. I only vaguely to probably not know what I’m talking about 
It’s just copying files right? I don’t see how this would be an issue on the Dynamo side. The error is with the robocopy, not any Dynamo functionality.
2 Likes
Do you have the same issues if you try to use xcopy?
Step though your bottlenecks:
- File exists
- File path exists
- Enough file space
- Access Permissions
- Antivirus software
- CMD copy function
There are a few things that you need to assess before getting to Dynamo being the culprit.
Good luck 
3 Likes
Not an issue I am seeing on the Dynamo side.
That error usually means you aren’t seeing the file, or see it but don’t have read access. My gut says your network drives are mapped differently on the new CPU, or a VPN issue, but only your IT team would know for sure… if you manually navigate to it does the file read/open?
1 Like
Thanks Jacob, can manually open from location
Thanks Ewan, xcopy didn’t seem to copy the files across or report an error.
How the copies set up currently. That was working before my computer update.
robocopy “From location” “To location” /MIR /MT:64
Is that location starting with C:\
Its a server location to local that was working before something changed, which seems like the issue could be with my new computer saving the file and permissions. Although I’m told its the same as my old
How big is the drive?
=>100 Gb?
The main server drive its on is greater then 100gigs. The stuff I’m copying is far less
If I copy an older dynamo file with a new name. Itll copy across. A new saved dynamo file wont. I’m going through the properties of the file and all the permissions are the same 
If I modify the old copied file in dynamo and save. It looses ability to copy across. Hmmm
sorry for spamming, actually looks like the owners different under details
Have you tried a blank Dynamo file saved from each version of Dynamo on your machine?
Dynamo2.2.dyn , Dynamo2.13.dyn, etc to see if there really is a versioning issue?
Robocopy doesn’t like it if the file is in use, I’ve had this when using the ‘open() and close()’ commands in python for text file editing. Check that the file and destination file aren’t in use? Network virus scan locking the file?
Could also be your network path formatting, I had similar issue a while back and it came down to which route was being taken via the network. We had a P:\Folder1\Folder2\File1.txt that would only copy if i used a full \server\domain\Folder1\Folder2\File1.txt path. I’ve taken to using the ‘os’ module in python and feeding most things through ‘os.path.normpath(file_path)’ just to be sure 
This could stem from your PC upgrade to a newer Windows?
1 Like
Sounds like the network has a ‘check’ in place to validate data before pushing it to end users. IT might have a scan that it has to pass, a cloud mirror may be under way, or another user could have opened it and locked it in doing so.
1 Like
If this is a network location, try using the UNC pathing vs lettered drives. I’ve begun doing this as we have users with different drive mappings in place.
3 Likes
Thanks appreciate the help. Its looking like it might be something in the graph. A blank updated graph is overwriting a new one
1 IT ran something to check things arn’t being used.
2 Been using UNC pathing.
Scrap everything. I’m now realizing I was probably remoting into a desktop computer when I made changes to the 3 difficult files copied to and stuck on peoples machines. So I’m going to find a way to clear out the files on everyone’s computers and be sure to make changes on my administrative computer that has whatever rights when copying to a computer after I save.
Many thanks! appreciate all the advice on troubleshooting. Hopefully it is what I’m thinking above 
1 Like