[ https://issues.apache.org/jira/browse/IO-707?focusedWorklogId=543378&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-543378 ]
ASF GitHub Bot logged work on IO-707: ------------------------------------- Author: ASF GitHub Bot Created on: 28/Jan/21 05:11 Start Date: 28/Jan/21 05:11 Worklog Time Spent: 10m Work Description: boris-unckel edited a comment on pull request #192: URL: https://github.com/apache/commons-io/pull/192#issuecomment-768802353 @garydgregory Thank you for your time to review and place it for public review. > If the pause happened before the assert, the assert catches something... if it happens after, I know nothing and my app calling Commons IO _still_ needs to handle the situation, assert or no assert. The use case you're describing is not improved by the assert or just slightly. I'm thinking more about cases where the underlying file system in combination with the JRE does not behave as expected: The following is a plain vanilla Fedora 33 with ext4 filesystem. Unfortunately in German :-( For /tmp it says "IOCTL not matching to read flags of /tmp". ``` sudo lsattr / [sudo] Passwort für borisunckel: -----------I--e----- /etc lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /run lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib64 --------------e----- /lost+found lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /sys --------------e----- /usr lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /proc --------------e----- /mnt lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /sbin --------------e----- /srv lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /tmp lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /bin --------------e----- /root --------------e----- /media --------------e----- /var --------------e----- /home lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /dev --------------e----- /boot --------------e----- /opt ``` Working with commons-io 2.5 I had no trouble to build WildFly-Core, with 2.8.0 it fails. The first fixes I already provided (former PRs not this one), but it is not over. A workaround is to set java.io.temp to a directory with "--------------e-----" attributes. The asserts help to find the original place of fail and not the top level one (like "delete fails due to directory is not empty"). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking ------------------- Worklog Id: (was: 543378) Time Spent: 1h 40m (was: 1.5h) > 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 40m > 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)