I have a weird situation that workspace rules do not work on one agent.
This is the rule:
\Deployments < $Workspace$%Configuration.OutputAgent%\Deployments*.zip
\Deployments\SingleClient\ < $Workspace$%Configuration.OutputAgent%\Deployments\SingleClient**.cab
On failing agent it seems as if rule is non existent and not that it did not find anything:
Update.
After reboot of agent and server, copy seems to work… 
Hi Michal,
The first thing we notice is that the agent that failed was using SSH instead of UNC as the transport method for copying the files between workspaces.
The agent reverts to the SSH transport method when it does not have access to the Continua CI share folder on the server. The SSH transport method is generally slower than UNC when the agent and server are on the same local network. If it is still using the SSH method after you rebooted, then we recommend that you check that the user the agent service is running under has read/write access to the share folder on the server.
The next thing we notice is that you are starting the agent part of the rule with $Workspace$. This is not required as workspace rules are rooted in the workspace folder, see Workspace Rules - Continua CI - VSoft Technologies Documentation Wiki.
The $Workspace$ expression expands to a local path and this still works with OK when using the UNC transport method, whereas the SSH transport method only works with relative paths. This explains why this is working with an agent using the UNC transport method, but not an agent using the SSH transport method.
We will include an update to the next version of Continua CI to automatically strip $Workspace$ from workspace rules. Meanwhile we recommend that you manually remove $Workspace$ from your workspace rules. e.g.
\Deployments < \%Configuration.OutputAgent%\Deployments*.zip
\Deployments\SingleClient\ < \%Configuration.OutputAgent%\Deployments\SingleClient**.cab
It’s not clear what changed after you rebooted the agent and server, maybe access to the Continua CI share folder was modified somehow? What transport method is logged for the build which worked after reboot?
Indeed it switched back to UNC.
Honestly I don’t know what changed after the reboot. For sure nothing in server or agent configuration…
But I have to add that this failing agent is a spare PC that we started using as an agent, it’s in a different network and has a different OS. Maybe it was some network hiccup that persisted until reboot…
Thank you for the fast support.