[jira] [Closed] (IO-707) Add optional early error detection as postcondition check
[ https://issues.apache.org/jira/browse/IO-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Unckel closed IO-707. --- Resolution: Won't Fix PR https://github.com/apache/commons-io/pull/192 was not successful. Bugs of commons-io are only accepted for Linux if they occur on CI which is Ubuntu. > Add optional early error detection as postcondition check > - > > Key: IO-707 > URL: https://issues.apache.org/jira/browse/IO-707 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > The current version does not include an optional way to detect errors with > the underlying filesystem and/or logic early. > Due to performance reason and/or design decision, the result of delete or > create directories/files does not include a check wheter the delete or create > was successful. It "only" relies on trust to the underlying operations of the > JDK and/or the completeness of own unit tests. > To have the option to check things, without having additional commons-io > proprietary options and without a performance impact for regular operations > the Java 1.4 keyword "assert" should be used. > Current project profits in case of detail analysis. Downstream projects > having own unit tests for IO will profit. > PR with proposal will follow. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IO-707) Add optional early error detection as postcondition check
[ https://issues.apache.org/jira/browse/IO-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280919#comment-17280919 ] Boris Unckel commented on IO-707: - [~beAshish] No, I don't have the necessary Jira access rights. > Add optional early error detection as postcondition check > - > > Key: IO-707 > URL: https://issues.apache.org/jira/browse/IO-707 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > The current version does not include an optional way to detect errors with > the underlying filesystem and/or logic early. > Due to performance reason and/or design decision, the result of delete or > create directories/files does not include a check wheter the delete or create > was successful. It "only" relies on trust to the underlying operations of the > JDK and/or the completeness of own unit tests. > To have the option to check things, without having additional commons-io > proprietary options and without a performance impact for regular operations > the Java 1.4 keyword "assert" should be used. > Current project profits in case of detail analysis. Downstream projects > having own unit tests for IO will profit. > PR with proposal will follow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IO-708) Utilize more java.nio for FileUtils and friends
[ https://issues.apache.org/jira/browse/IO-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Unckel closed IO-708. --- Resolution: Won't Fix > Utilize more java.nio for FileUtils and friends > --- > > Key: IO-708 > URL: https://issues.apache.org/jira/browse/IO-708 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Currently o.a.c.io.FileUtils use a lot of java.io.File methods (exists, > delete...). This should be migrated to java.nio.files.Files methods. > Advantage: All nio IOExceptions are more expressive -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-522) Symbolic links get followed in deleteQuietly
[ https://issues.apache.org/jira/browse/IO-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17274393#comment-17274393 ] Boris Unckel commented on IO-522: - This has been solved [https://github.com/apache/commons-io/blob/fa59009aaabcf8671a8d741993ef355f42b95ccd/src/main/java/org/apache/commons/io/file/DeletingPathVisitor.java#L136] Please close the issue. > Symbolic links get followed in deleteQuietly > > > Key: IO-522 > URL: https://issues.apache.org/jira/browse/IO-522 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.5 >Reporter: Daniel Temme >Assignee: Stian Soiland-Reyes >Priority: Critical > > IO-168 describes the problem. > `deleteQuietly` will behave correctly for nested symlinks but the initial > call erroneously calls `cleanDirectory`. Calling `deleteDirectory` and > returning would probably be the better behaviour (analogous to `forceDelete`) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IO-710) Utilize java.io.UncheckedIOException, rethrow SecurityException
[ https://issues.apache.org/jira/browse/IO-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Unckel closed IO-710. --- Resolution: Won't Fix > Utilize java.io.UncheckedIOException, rethrow SecurityException > --- > > Key: IO-710 > URL: https://issues.apache.org/jira/browse/IO-710 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Some methods catch IOExceptions and rethrow them in other RuntimeException > based exceptions (IllegalStateException, IllegalArgumentException). > The JRE offers a standard for this usecase: java.io.UncheckedIOException > In one case a SecurityException would be hidden. This is awfull if you're > trying to find the right set of permissions to make the SecurityManager work. > The default must be to rethrow them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-712) SecurityExceptions are hidden instead of breaking the regular flow
[ https://issues.apache.org/jira/browse/IO-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Unckel updated IO-712: Labels: Security SecurityManager (was: ) > SecurityExceptions are hidden instead of breaking the regular flow > -- > > Key: IO-712 > URL: https://issues.apache.org/jira/browse/IO-712 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Critical > Labels: Security, SecurityManager > Time Spent: 10m > Remaining Estimate: 0h > > Several points in the code hide SecurityException. These _must_ always > _break_ the regular control flow, if you're not the SecurityManager. > UseCase A: One wants to configure the SecurityManager and grant permissions. > Part of the application is to delete a file. If the permission is missing, > cleaning does not work. The missing exception does not allow to recognize > that. > UseCase B: One has activated the SecurityManager. An attacker abuses the > relevant method. The missing SecurityException hides this attempt, ones IDS > can't alarm. > UseCase C: One utilizes the SecurityManager to test the system, to ensure > every property (like file location) is set properly. The missing > SecurityException does not support this UseCase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-712) SecurityExceptions are hidden instead of breaking the regular flow
Boris Unckel created IO-712: --- Summary: SecurityExceptions are hidden instead of breaking the regular flow Key: IO-712 URL: https://issues.apache.org/jira/browse/IO-712 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel Several points in the code hide SecurityException. These _must_ always _break_ the regular control flow, if you're not the SecurityManager. UseCase A: One wants to configure the SecurityManager and grant permissions. Part of the application is to delete a file. If the permission is missing, cleaning does not work. The missing exception does not allow to recognize that. UseCase B: One has activated the SecurityManager. An attacker abuses the relevant method. The missing SecurityException hides this attempt, ones IDS can't alarm. UseCase C: One utilizes the SecurityManager to test the system, to ensure every property (like file location) is set properly. The missing SecurityException does not support this UseCase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-711) Use Objects.requireNotNull for fail fast method/constructors
Boris Unckel created IO-711: --- Summary: Use Objects.requireNotNull for fail fast method/constructors Key: IO-711 URL: https://issues.apache.org/jira/browse/IO-711 Project: Commons IO Issue Type: Improvement Components: Filters, Streams/Writers, Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel Currently some NullPointer checks are IllegalArgumentException, at other points a lot of constructor and/or method logic happens before a null pointer occurs. The approach is to make these places use Objects.requireNonNull(sampleObject,"sampleObject"); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-710) Utilize java.io.UncheckedIOException, rethrow SecurityException
Boris Unckel created IO-710: --- Summary: Utilize java.io.UncheckedIOException, rethrow SecurityException Key: IO-710 URL: https://issues.apache.org/jira/browse/IO-710 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel Some methods catch IOExceptions and rethrow them in other RuntimeException based exceptions (IllegalStateException, IllegalArgumentException). The JRE offers a standard for this usecase: java.io.UncheckedIOException In one case a SecurityException would be hidden. This is awfull if you're trying to find the right set of permissions to make the SecurityManager work. The default must be to rethrow them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-709) Add null safe variants of isDirectory and isRegularFile
Boris Unckel created IO-709: --- Summary: Add null safe variants of isDirectory and isRegularFile Key: IO-709 URL: https://issues.apache.org/jira/browse/IO-709 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel Add null safe variants of the java.nio.file.Files.isDirectory and java.nio.file.Files.isRegular for both Path and File parameters. Direct usage will be later in refactoring FileUtils to nio. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-708) Utilize more java.nio for FileUtils and friends
Boris Unckel created IO-708: --- Summary: Utilize more java.nio for FileUtils and friends Key: IO-708 URL: https://issues.apache.org/jira/browse/IO-708 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel Currently o.a.c.io.FileUtils use a lot of java.io.File methods (exists, delete...). This should be migrated to java.nio.files.Files methods. Advantage: All nio IOExceptions are more expressive -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-707) Add optional early error detection as postcondition check
Boris Unckel created IO-707: --- Summary: Add optional early error detection as postcondition check Key: IO-707 URL: https://issues.apache.org/jira/browse/IO-707 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.8.0 Reporter: Boris Unckel The current version does not include an optional way to detect errors with the underlying filesystem and/or logic early. Due to performance reason and/or design decision, the result of delete or create directories/files does not include a check wheter the delete or create was successful. It "only" relies on trust to the underlying operations of the JDK and/or the completeness of own unit tests. To have the option to check things, without having additional commons-io proprietary options and without a performance impact for regular operations the Java 1.4 keyword "assert" should be used. Current project profits in case of detail analysis. Downstream projects having own unit tests for IO will profit. PR with proposal will follow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IO-702) FileUtils.forceDelete does not delete invalid links
[
https://issues.apache.org/jira/browse/IO-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Unckel closed IO-702.
---
OK. Thank you!
> FileUtils.forceDelete does not delete invalid links
> ---
>
> Key: IO-702
> URL: https://issues.apache.org/jira/browse/IO-702
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Boris Unckel
>Priority: Critical
> Fix For: 2.9.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current implementation of FileUtils.forceDelete does not delete invalid
> links. Invalid links means one pointing to a non existing directory. This is
> _not related_ to the intended behaviour to _keep the destination_ of the link.
> The FileUtils.cleanDirectory is based on forceDelete but does not check the
> result. FileUtils.cleanDirectory assumes "no exception" means "directory is
> clean".
> FileUtils.deleteDirectory fails with "directory not empty".
> Testcase result (will provide that)
> {code:java}
> java.nio.file.DirectoryNotEmptyException:
> /tmp/junit4962570063696933090/realParentDirC
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1146)
> at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
> at
> org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IO-702) FileUtils.forceDelete does not delete invalid links
Boris Unckel created IO-702:
---
Summary: FileUtils.forceDelete does not delete invalid links
Key: IO-702
URL: https://issues.apache.org/jira/browse/IO-702
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.8.0
Reporter: Boris Unckel
The current implementation of FileUtils.forceDelete does not delete invalid
links. Invalid links means one pointing to a non existing directory. This is
_not related_ to the intended behaviour to _keep the destination_ of the link.
The FileUtils.cleanDirectory is based on forceDelete but does not check the
result. FileUtils.cleanDirectory assumes "no exception" means "directory is
clean".
FileUtils.deleteDirectory fails with "directory not empty".
Testcase result (will provide that)
{code:java}
java.nio.file.DirectoryNotEmptyException:
/tmp/junit4962570063696933090/realParentDirC
at
java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
at
java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
at java.base/java.nio.file.Files.delete(Files.java:1146)
at org.apache.commons.io.FileUtils.delete(FileUtils.java:1173)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1192)
at
org.apache.commons.io.FileUtilsDeleteDirectoryBaseTestCase.testDeleteInvalidLinks(FileUtilsDeleteDirectoryBaseTestCase.java:216)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-701) PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
[
https://issues.apache.org/jira/browse/IO-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265754#comment-17265754
]
Boris Unckel commented on IO-701:
-
Integration test works. Thank you.
> PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
>
>
> Key: IO-701
> URL: https://issues.apache.org/jira/browse/IO-701
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: java --version
> openjdk 11.0.9.1 2020-11-04
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)
> cat /etc/fedora-release
> Fedora release 33 (Thirty Three)
> uname -a
> Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> # /etc/fstab
> # Created by anaconda on Sat Aug 29 05:35:21 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/fedora_localhost--live-root / ext4
> defaults1 1
> UUID=fd3a2229-bdf5-4fe5-b596-141b9d6c609f /boot ext4
> defaults1 2
> UUID=0C7E-FC8E /boot/efi vfat
> umask=0077,shortname=winnt 0 2
> /dev/mapper/fedora_localhost--live-home /home ext4
> defaults1 2
> /dev/mapper/fedora_localhost--live-swap noneswap
> defaults0 0
>Reporter: Boris Unckel
>Priority: Critical
> Fix For: 2.9.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
> Exception, a second try with PosixFileAttributeView will not be done.
> The approach is to catch a IOException (java.nio.file.FileSystemException
> Operation not supported), add it to a exception list. Throw the exception
> list if not empty.
> Please check the environment of this bug: integration tests are all run on
> Ubuntu. This occured on Fedora. (Maybe the difference is ext4 ?)
> Example stacktrace (Message is "Operation not supported")
> {code:java}
> java.nio.file.FileSystemException:
> /tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
> unterstützt
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
> at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
> at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
> at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:393)
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1337)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:303)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
> at
> org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:299)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IO-701) PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
[
https://issues.apache.org/jira/browse/IO-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Unckel closed IO-701.
---
> PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
>
>
> Key: IO-701
> URL: https://issues.apache.org/jira/browse/IO-701
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: java --version
> openjdk 11.0.9.1 2020-11-04
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)
> cat /etc/fedora-release
> Fedora release 33 (Thirty Three)
> uname -a
> Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> # /etc/fstab
> # Created by anaconda on Sat Aug 29 05:35:21 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/fedora_localhost--live-root / ext4
> defaults1 1
> UUID=fd3a2229-bdf5-4fe5-b596-141b9d6c609f /boot ext4
> defaults1 2
> UUID=0C7E-FC8E /boot/efi vfat
> umask=0077,shortname=winnt 0 2
> /dev/mapper/fedora_localhost--live-home /home ext4
> defaults1 2
> /dev/mapper/fedora_localhost--live-swap noneswap
> defaults0 0
>Reporter: Boris Unckel
>Priority: Critical
> Fix For: 2.9.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
> Exception, a second try with PosixFileAttributeView will not be done.
> The approach is to catch a IOException (java.nio.file.FileSystemException
> Operation not supported), add it to a exception list. Throw the exception
> list if not empty.
> Please check the environment of this bug: integration tests are all run on
> Ubuntu. This occured on Fedora. (Maybe the difference is ext4 ?)
> Example stacktrace (Message is "Operation not supported")
> {code:java}
> java.nio.file.FileSystemException:
> /tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
> unterstützt
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
> at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
> at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
> at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:393)
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1337)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:303)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
> at
> org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:299)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IO-701) PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
[
https://issues.apache.org/jira/browse/IO-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Unckel updated IO-701:
Description:
PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
Exception, a second try with PosixFileAttributeView will not be done.
The approach is to catch a IOException (java.nio.file.FileSystemException
Operation not supported), add it to a exception list. Throw the exception list
if not empty.
Please check the environment of this bug: integration tests are all run on
Ubuntu. This occured on Fedora. (Maybe the difference is ext4 ?)
Example stacktrace (Message is "Operation not supported")
{code:java}
java.nio.file.FileSystemException:
/tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
unterstützt
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:393)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1337)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:303)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:299)
{code}
was:
PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
Exception, a second try with PosixFileAttributeView will not be done.
The approach is to catch a IOException (java.nio.file.FileSystemException
Operation not supported), add it to a exception list. Throw the exception list
if not empty.
Example stacktrace (Message is "Operation not supported")
{code:java}
java.nio.file.FileSystemException:
/tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
unterstützt
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:393)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1337)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:303)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:299)
{code}
> PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
>
>
> Key: IO-701
> URL: https://issues.apache.org/jira/browse/IO-701
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: java --version
> openjdk 11.0.9.1 2020-11-04
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)
> cat /etc/fedora-release
> Fedora release 33 (Thirty Three)
> uname -a
> Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> # /etc/fstab
> # Created by anaconda on Sat Aug 29 05:35:21 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/fedora_localhost--live-root / ext4
> defaults1 1
> UUID=fd3a2229-bdf5-4fe5-b596-141b9d6c609f /boot ext4
> defaults1 2
> UUID=0C7E-FC8E /boot/efi vfat
> umask=0077,shortname=winnt 0 2
> /dev/mapper/fedora_localhost--live-home /home ext4
> defaults1 2
> /dev/mapper/fedora_
[jira] [Updated] (IO-701) PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
[
https://issues.apache.org/jira/browse/IO-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Unckel updated IO-701:
Description:
PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
Exception, a second try with PosixFileAttributeView will not be done.
The approach is to catch a IOException (java.nio.file.FileSystemException
Operation not supported), add it to a exception list. Throw the exception list
if not empty.
Example stacktrace (Message is "Operation not supported")
{code:java}
java.nio.file.FileSystemException:
/tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
unterstützt
at
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
at
java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:393)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1337)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:303)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1189)
at
org.apache.commons.io.FileUtilsTestCase.setUp(FileUtilsTestCase.java:299)
{code}
was:
PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
Exception, a second try with PosixFileAttributeView will not be done.
The approach is to catch a IOException (java.nio.file.FileSystemException
Operation not supported), add it to a exception list. Throw the exception list
if not empty.
> PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
>
>
> Key: IO-701
> URL: https://issues.apache.org/jira/browse/IO-701
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: java --version
> openjdk 11.0.9.1 2020-11-04
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)
> cat /etc/fedora-release
> Fedora release 33 (Thirty Three)
> uname -a
> Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> # /etc/fstab
> # Created by anaconda on Sat Aug 29 05:35:21 2020
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> /dev/mapper/fedora_localhost--live-root / ext4
> defaults1 1
> UUID=fd3a2229-bdf5-4fe5-b596-141b9d6c609f /boot ext4
> defaults1 2
> UUID=0C7E-FC8E /boot/efi vfat
> umask=0077,shortname=winnt 0 2
> /dev/mapper/fedora_localhost--live-home /home ext4
> defaults1 2
> /dev/mapper/fedora_localhost--live-swap noneswap
> defaults0 0
>Reporter: Boris Unckel
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a
> Exception, a second try with PosixFileAttributeView will not be done.
> The approach is to catch a IOException (java.nio.file.FileSystemException
> Operation not supported), add it to a exception list. Throw the exception
> list if not empty.
> Example stacktrace (Message is "Operation not supported")
> {code:java}
> java.nio.file.FileSystemException:
> /tmp/junit4674316189874192997/file1-test.txt: Die Operation wird nicht
> unterstützt
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.updateDosAttribute(LinuxDosFileAttributeView.java:278)
> at
> java.base/sun.nio.fs.LinuxDosFileAttributeView.setReadOnly(LinuxDosFileAttributeView.java:191)
> at org.apache.commons.io.file.PathUtils.setReadOnly(PathUtils.java:876)
> at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:486)
[jira] [Created] (IO-701) PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView
Boris Unckel created IO-701: --- Summary: PathUtils.setReadOnly do not deal with LinuxDosFileAttributeView Key: IO-701 URL: https://issues.apache.org/jira/browse/IO-701 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.8.0 Environment: java --version openjdk 11.0.9.1 2020-11-04 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode) cat /etc/fedora-release Fedora release 33 (Thirty Three) uname -a Linux localhost.localdomain 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux # /etc/fstab # Created by anaconda on Sat Aug 29 05:35:21 2020 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # /dev/mapper/fedora_localhost--live-root / ext4 defaults1 1 UUID=fd3a2229-bdf5-4fe5-b596-141b9d6c609f /boot ext4 defaults1 2 UUID=0C7E-FC8E /boot/efi vfat umask=0077,shortname=winnt 0 2 /dev/mapper/fedora_localhost--live-home /home ext4 defaults1 2 /dev/mapper/fedora_localhost--live-swap noneswap defaults0 0 Reporter: Boris Unckel PathUtils.setReadOnly use a DosFileAttributeView first. If this fails with a Exception, a second try with PosixFileAttributeView will not be done. The approach is to catch a IOException (java.nio.file.FileSystemException Operation not supported), add it to a exception list. Throw the exception list if not empty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
