[ 
https://issues.apache.org/jira/browse/IO-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702951#comment-17702951
 ] 

Gary D. Gregory commented on IO-787:
------------------------------------

Hello [~remirosenthal] 

What happens if you use 2.12-SNAPSHOT from 
[https://repository.apache.org/content/repositories/snapshots/commons-io/commons-io/2.12.0-SNAPSHOT/]
 ?

> FileUtils.forceDelete(File file) fails on MacOS
> -----------------------------------------------
>
>                 Key: IO-787
>                 URL: https://issues.apache.org/jira/browse/IO-787
>             Project: Commons IO
>          Issue Type: Bug
>    Affects Versions: 2.11.0
>         Environment: macOS Monterey version 12.2.1
> Java Info: Vendor 'Oracle Corporation' URL 'https://java.oracle.com/' Version 
> '17.0.6' Home '/Library/Java/JavaVirtualMachines/jdk-17.0.6.jdk/Contents/Home'
>            Reporter: Remi Rosenthal
>            Priority: Major
>         Attachments: Chromium.app.zip
>
>
> My codebase has been using FileUtils.cleanDirectory for a while now. Since 
> upgrading from 2.6 to 2.11.0, we found that the operation sometimes throws an 
> AccessDeniedException on MacOS but not on the other platforms. More 
> specifically, 2.8.0 is fine but 2.9.0 onward has the problem.
> FileUtils.cleanDirectory calls FileUtils.forceDelete where I believe the 
> problem originates.
> I have not been able to narrow down the necessary conditions to reproduce 
> with 100% confidence but hopefully the contents of the attached zip should 
> preserve those conditions on another Mac machine.
> Then, to reproduce, simply try and call:
> {code:java}
> FileUtils.forceDelete(file);{code}
> on the Chromium.app file.
> For me, the resulting stack trace looks like this:
>  
> {code:java}
> java.io.IOException: Cannot delete file: 
> /var/folders/4f/4njp3j594893v3y136b6w1z80000gn/T/temp/Chromium.app
>     at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1344)
>     at org.myproject.MyTest.testDeleteReadOnlyFile(MyTest.java:107)
>     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>     at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>     at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>     at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>     at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>     ...
> Caused by: java.nio.file.AccessDeniedException: 
> /var/folders/4f/4njp3j594893v3y136b6w1z80000gn/T/temp/Chromium.app/Contents/Frameworks/Chromium
>  Framework.framework/Versions/105.0.5195.0/_CodeSignature
>     at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
>     at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
>     at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>     at 
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:248)
>     at 
> java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110)
>     at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
>     at 
> org.apache.commons.io.file.DeletingPathVisitor.postVisitDirectory(DeletingPathVisitor.java:142)
>     at 
> org.apache.commons.io.file.DeletingPathVisitor.postVisitDirectory(DeletingPathVisitor.java:37)
>     at java.base/java.nio.file.Files.walkFileTree(Files.java:2828)
>     at java.base/java.nio.file.Files.walkFileTree(Files.java:2882)
>     at org.apache.commons.io.file.PathUtils.visitFileTree(PathUtils.java:971)
>     at 
> org.apache.commons.io.file.PathUtils.deleteDirectory(PathUtils.java:434)
>     at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:391)
>     at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1341)
>     ... 71 more
> {code}
>  
> Strangely, the folder "_CodeSignature" doesn't appear to be read-only.
> Through bisecting I have narrowed down the commit that introduced the failure 
> to {_}8ae947bcc796d73b0eab7d94f10a002f66896af3{_}.
> The changeset caused FileUtils.forceDelete to call PathUtils.delete with a 
> StandardDeleteOption.OVERRIDE_READ_ONLY flag. This sounds like it should help 
> delete read-only files but for some reason does the opposite on MacOS in this 
> instance. Indeed, a build of commons-io 2.11.0 with this change reverted 
> allows my file to be deleted.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to