Does it work when you copy to/from a directory other than `projectDir`?

Yes. This works:

task myCopy(type: Copy) {
from 'test.xml'
into 'newdir'
rename

}

The problem is only when I try to copy to the same directory.

Hmm...

I copied the project to a Linux server and the code worked as expected!

It looks like there's a bug in Gradle's Copy task under Windows XP. The developers here work in XP, so I guess I'll have to use the ant copy task until it gets fixed.

Does it work when you copy to/from the same directory but not `projectDir`?

Yes. This works fine:

task myCopy(type: Copy) {
from 'newdir/test2.xml'
into 'newdir'
rename

}

So it only seems to be a problem copying around in the project directory. My solution (for now):

ant.copy(file: 'test.xml', tofile: 'test2.xml' )

Actually, now that I look at it, the ant call is clearer and more concise. I think I'll just use that from now on.

So, I found that this issue must have been fixed, in gradle 1.9 or earlier, at least partially. I am experiencing similar file locking issues on a simple copy and rename to the rootProject's directory, within a multi-project build.

task copyMasterMakefile(type: Copy) {
from masterMakefile
into rootProject.getProjectDir()
rename

}

$ gradlew copyMasterMakefile
:oldBuildscripts:copyMasterMakefile

FAILURE: Build failed with an exception.

• What went wrong:
  java.io.IOException: The process cannot access the file because another process has locked a portion of the file
  > The process cannot access the file because another process has locked a portion of the file

Sorry to reopen this thread. I wasn't sure if there was an issue that I could post this to.

As I said, the single file copy and rename to the subproject's directory works as expected.

task copyMasterMakefile(type: Copy) {
from masterMakefile
into getProjectDir()
rename

}

$ cat gradle/wrapper/gradle-wrapper.properties | grep distributionUrl
distributionUrl=http\://services.gradle.org/distributions/gradle-1.9-bin.zip
$ gradlew copyMasterMakefile
:oldBuildscripts:copyMasterMakefile

BUILD SUCCESSFUL

Total time: 7.737 secs
$ ls -larth subprojects/old-buildscripts/Makefile
rw-rr- 1 kevinm Administ 19k Jan 9 14:04 subprojects/old-buildscripts/Makefile

Kevin,

Could you supply a self contained build that exhibits the problem?

Sure. I'll work on it and get back to you.

Reproducible test case for my rootProject locking issue

...yes, I'm on windows, despite the fact that I like to work in a bash shell ...

• Project setup:

kevinm@xxx /d/repos/temp
$ gradle init
:wrapper
:init

BUILD SUCCESSFUL

Total time: 3.306 secs
kevinm@xxx /d/repos/temp
$ mkdir foo
kevinm@xxx /d/repos/temp
$ cd foo
kevinm@xxx /d/repos/temp/foo
$ echo "foobar" > foo.txt

• Modify settings.gradle:

...
/*
// To declare projects as part of a multi-project build use the 'include' method
include 'shared'
include 'api'
include 'services:webservice'
*/

rootProject.name = 'temp'
include 'foo'

• Modify foo's build.gradle (e.g. `d:\repos\temp\foo\build.gradle`):

ext {
afile = 'foo.txt'
}

task copyFile(type: Copy) {
from afile
into rootProject.getProjectDir()
}

• Run gradle wrapper with 'copyFile' task:

kevinm@xxx /d/repos/temp
$ gradlew copyFile
:foo:copyFile

FAILURE: Build failed with an exception.

• What went wrong:
  java.io.IOException: The process cannot access the file because another process has locked a portion of the file
  > The process cannot access the file because another process has locked a portion of the file

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 5.679 secs

I hope that helps. Let me know if this still isn't reproducible. I would love for this to be some dumb environmental issue on my end.

I've also wondered if specifying the `into` property as `rootProject.getProjectDir()` may be the issue, but I wasn't quite sure how else to get that value. That is proper usage, correct?

in general passing rootProject.getProjectDir should work fine

Hello Kevin,
many thanks for the self-contained example. I can reproduce this problem now and will create an issue for that in the gradle issue tracker.

the example-snippet.zip contains a minimal reproducable example of the problem. Reproduced with windows7 and gradle 1.10

I am facing this issue in 2.0 when run in Windows 7 although it works when tested in OS X. Here is a simple task that I use to explode a zip and copy its content to a directory (in the same directory).

task extractSchema(type: Copy) {
    from zipTree( "xyz.zip" )
    into "C:\\Users\\dmahapatro\\Desktop\\backup"
}

Any workaround to make Copy task work properly in Windows?

The only workaround I found so far (thank to @kingkong from forum post) is to define your own copy action, and not rely on the Copy base task. However, be sure to specify task's inputs and outputs unless what, the copy will always occur. This is probably not workable when copying multiple files, like form a zip because you would need to specify each files in some way.

task copyToProjectDir() { 
  inputs.file "/path/to/Makefile"
  outputs.file "$projectDir/Makefile"

  doLast {
    copy {
      from "/path/to/Makefile"
      into projectDir
    } 
  }
}

This works for explicit files, but will fail with the same error if outputs is the project directory directly like outputs.dir projectDir. In this case, we return to the same problem as the Copy task.

One solution I thought when copying specific files would be to change custom Copy task's outputs definition to point to a specific file:

task copyToProjectDir(type: Copy) {
  outputs.file "$projectDir/Makefile"

  from "/path/to/Makefile"
  into projectDir
}

But this does not seem to make it, I think because the default outputs inferred by the base Copy task are still applied. Maybe it's possible to completely change task's outputs? I tried using a upToDateWhen call with a closure, not much luck.

I got it working with a zip file, at least kind of. Of course the up-to-date check will not recognize if unzipped files have been removed or changed since the last unzip, but at least it recognizes a new/unchanged zip file:

	task testZip(type: Copy) {
		from zipTree("someZip.zip")
		into rootProject.projectDir
		outputs.files.setFrom(project.file("someZip.zip"))
	}

To clean the outputs you explicitly have to call setFrom on the outputs.files FileCollection, most other methods like outputs.file, outputs.dir or outputs.files.from will only add to outputs.files.
I also tried around with excluding the problematic cache directory from the output.files FileCollection but unfortunately it is final in DefaultTaskOutputs. All methods in DefaultConfigurableFileCollection (used for outputs.files) that would allow filtering or subtraction return a new collection which i cannot put to outputs.files

PS:
According to what I said above, I suppose that Matthieu's example should work as follows:

task copyToProjectDir(type:Copy) {
   outputs.files.setFrom(project.file("$projectDir/Makefile"))
   from "/path/to/Makefile"
   into projectDir
}

Thank you Ronald Brindl, this is exactly what I was looking for. Skimming in the documentation, I had not found a way to completely replaces files collection. This seems that it's the way to go.

I will test it in my project later on today and report my finding.

Cheers,
Matt

@Ronald Brindl, tested your workaround and it worked like a charm. Hence explicitly setting the outputs files is probably the best workaround we can achieve.

task copyToProjectDir(type: Copy) {
  outputs.files.setFrom(file("$projectDir/Makefile"))

  from file("doc/Makefile")
  into projectDir
}

I'm trying to use the workaround proposed but I have this error running the setFrom method:

No signature of method: org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection.SetFrom() is applicable for argument types: (java.io.File)

I've tried simply use
outputs.file(file("pathToElement"))
but I still have the error.

How do you have resolved this?

Strange because the method setFrom from ConfigurableFileCollection#setFrom still exists and takes a varagrs of Object. Hence, a java.io.File should be accepted.

My current exact code is written above and it works since the time I posted it. You are probably doing something different. The method javadoc say setFrom arguments are resolved using Project.files(Object...), you could try outputs.files.setFrom("pathToElement") to see if it works. The String argument should be resolved like if you had called file("pathToElement") directly.

Please post a bigger snippet of your Copy task so we can help you better.

Cheers,
Matt

I've seen the javadoc.. The main difference I see is that mine is defined inside a plugin task:

class BootstrapPlugin implements Plugin<Project> {
	void apply(Project project){
		project.afterEvaluate {
			project.configurations.bootstrap.each { element ->
				if(element.name.endsWith(".zip")){
					project.task("unzipSingle${element.name}", type: Copy){
					
						outputs.files.SetFrom(project.file(element.path))
						
						from project.zipTree(element)
						into project.file(unpackLocation)

But I've not understand in what the SetFrom method behaves different from setting

outputs.file(project.file(element.path)))

which does not give compilation errors, but does not resolve the lock problem.

I'm also doing this in a plugin an it works here.

The method names are case sensitive, it should be setFrom (with a lower case `s`) and * not* SetFrom. Trying SetFrom in a small test case:

task('testing', type: Copy) {
    outputs.files.SetFrom(file('Testing'))

	from 'source'
	into 'directory'
}

* Where:
Build file 'C:\Gnu\tmp\gradle-3002\build.gradle' line: 3

* What went wrong:
A problem occurred evaluating root project 'gradle-3002'.
> No signature of method: org.gradle.api.internal.file.collections.DefaultConfigurableFileCollection.SetFrom() is applicable for argument types: (java.io.File) values: [C:\Gnu\tmp\gradle-3002\Testing]
Possible solutions: getFrom(), setFrom([Ljava.lang.Object;), setFrom(java.lang.Iterable), from([Ljava.lang.Object;)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

The case sensitiveness applies to all method you see in the Gradle API reference documentation.

You're right. It works. Sorry for the silly question. Thank you.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

This is still a bug.

Given that this issue is specific to Windows and the project root directory and the fact that there is a simple workaround `ant.copy(file: 'test.xml', tofile: 'test2.xml')` the motivation for addressing this is low and therefore I'm marking this wontfix.