[
https://issues.apache.org/jira/browse/IO-707?focusedWorklogId=543376&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-543376
]
ASF GitHub Bot logged work on IO-707:
-------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jan/21 05:10
Start Date: 28/Jan/21 05:10
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: 543376)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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)
