wma created IO-757:
----------------------
Summary: listFilesAndDirs doesn't list symbolicLinks when the
original file has been deleted. The link does exist on OS
Key: IO-757
URL: https://issues.apache.org/jira/browse/IO-757
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.9.0
Environment: Discovered on macOS Monterey 12.0.1 on Apple M1 Max
openjdk version "11.0.13" 2021-10-19 LTS
OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
OpenJDK 64-Bit Server VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)
Reporter: wma
Attachments: commons-io-bug.zip
When upgrading from version 2.8.0 to 2.11.0 i found out a difference in
behaviour in the FileUtils.listFilesAndDirs method concerning symbolic links. I
tracked it back to version 2.9.0 that introduced it. On the changelist of that
release I found following that might be related/caused it:
{quote}FileUtils.iterateFiles runs out of memory when executed for a directory
with large number of files. Re-implement FileUtils' iterateFiles(),
iterateFilesAndDirs(), listFiles(), listFilesAndDirs() to use NIO file tree
walking instead of IO file listings to avoid memory consumption issues on large
file trees. Fixes IO-597. Thanks to Gary Gregory, Arvind, Rob Spoor.
{quote}
The testcase is following:
1. create a file F in a directory D
2. create a symbolic link S to F in D
3. call FileUtils.listFilesAndDirs for D to verify setup is ok
-> The results is 3 items, D, F and S
4. delete file F
5. call FileUtils.listFilesAndDirs for D
-> Before release 2.9.0 the result here is 2 items. D and S, from release 2.9.0
on, the result is 1 item, only D. The symbolic link is not listed anymore while
it does exist on disk still.
I call this a bug as the result does not reflect the situation on disk and
Files.list does show the symbolic link
Included unit test project, succeeds when using version 2.8.0, fails when using
2.9.0
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
