[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elliotte Rusty Harold updated IO-663:
-------------------------------------
    Description: 
This bug is shared (likely because of code copied from one place to another) 
between the similar methods in commons IO, codehaus-plexus-utils, and 
maven-shared-utils. 

I don't have an isolated test case because this bug is platform specific and 
I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I 
don't have a Windows system handy to test it. However it is reproducible. 

Typical code that triggers it is in RestoreBackupPomsPhaseTest in maven-release:

{{        
       // copy poms so tests are valid without clean
        File sourceDir = getTestFile( "src/test/resources" + projectPath );
        File testDir = getTestFile( "target/test-classes" + projectPath );
        FileUtils.copyDirectoryStructure( sourceDir, testDir );
}}


I don't know whether there might be something weird in the setup of those two 
directories that's involved. 


Typical error message is:

Caused by: java.nio.file.FileSystemException:
F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
 The process cannot access the file because it is being used by another process

"The process cannot access the file because it is being used by another 
process" I think points to the root of the bug. This is a Windows file system 
error message.

Some history is here where I noticed it:

https://github.com/apache/maven-release/pull/42

In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
from both maven-shared-utils and commons-io, all of which failed in the same 
way. 

I think this is caused by the use of NIO, which doesn't work quite the same 
when copying files on Windows as on Linux and Mac OS X.


  was:
This bug is shared (likely because of code copied from one place to another) 
between the similar methods in commons IO, codehaus-plexus-utils, and 
maven-shared-utils.

I don't have an isolated test case because this bug is platform specific and 
I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I 
don't have a Windows system handy to test it. However it is reproducible.

Typical code that triggers it is in RestoreBackupPomsPhaseTest in maven-release:

{{// copy poms so tests are valid without clean}}
{{ File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
{{ File testDir = getTestFile( "target/test-classes" + projectPath );}}
{{ FileUtils.copyDirectoryStructure( sourceDir, testDir );}}

I don't know whether there might be something weird in the setup of those two 
directories that's involved.

Typical error message is:

Caused by: java.nio.file.FileSystemException:
 
F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
 The process cannot access the file because it is being used by another process

"The process cannot access the file because it is being used by another 
process" I think points to the root of the bug. This is a Windows file system 
error message.

Some history is here where I noticed it:

[https://github.com/apache/maven-release/pull/42]

In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
from both maven-shared-utils and commons-io, all of which failed in the same 
way.

I think this is caused by the use of NIO, which doesn't work quite the same 
when copying files on Windows as on Linux and Mac OS X.


> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> -------------------------------------------------------------------
>
>                 Key: IO-663
>                 URL: https://issues.apache.org/jira/browse/IO-663
>             Project: Commons IO
>          Issue Type: Bug
>            Reporter: Elliotte Rusty Harold
>            Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils. 
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible. 
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{        
>        // copy poms so tests are valid without clean
>         File sourceDir = getTestFile( "src/test/resources" + projectPath );
>         File testDir = getTestFile( "target/test-classes" + projectPath );
>         FileUtils.copyDirectoryStructure( sourceDir, testDir );
> }}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved. 
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> https://github.com/apache/maven-release/pull/42
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way. 
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to