To copy files into your deployments folder, we first copy it to a temporary folder (In your case
C:\wildfly-8.1.0.Final\standalone\tmp\) and then attempt to do a file.renameTo(new path). This command can fail if for example you mark your temporary folder as d:\tmp and your deployments folder as
This doesn't appear to be the case in your example, though. So far we haven't had anyone report this issue (at least in this release) so I think it'd be best if we opened a jira to track it and make sure it gets tested by others.
Some possible things that you could do to help us debug it, though, are, after you replicate, can you verify:
C:\wildfly-8.1.0.Final\standalone\deployments\<war-name>.war exists, and
C:\wildfly-8.1.0.Final\standalone\deployments\<war-name>.war is not a file / war archive, but is in fact a folder
Obviously we should be able to handle either issue, but, it's always possible that there's a bug somewhere that simply wasn't caught, which would be sad.
to help track the issue.
I've opened [JBIDE-18697] Error deploying exploded war on windows; fs / copy error - JBoss Issue Tracker
Thanks, Rob Stryker.
I'm sure C:\wildfly-8.1.0.Final\standalone\deployments\<war-name>.war is a folder, not a file.
I updated [JBIDE-18697] Error deploying exploded war on windows; fs / copy error with the steps to reproduce the issue.