Uploaded image for project: 'Commons IO'
  1. Commons IO
  2. IO-757

listFilesAndDirs doesn't list symbolicLinks when the original file has been deleted. The link does exist on OS



    • Bug
    • Status: Resolved
    • Major
    • Resolution: Information Provided
    • 2.9.0
    • 2.12.0
    • Utilities
    • None


      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:

      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.

      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


        1. commons-io-bug.zip
          104 kB



            Unassigned Unassigned
            wma wma
            0 Vote for this issue
            2 Start watching this issue