JDK-6907737 : (file) FileVisitor and Files.walkFileTree issues
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-12-06
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7 b114Fixed
Related Reports
Duplicate :  
Relates :  
This bug is tracking the following issues with Files.walkFileTree that need to fixed:

1. The visit* methods defined by FileVisitor will typically do I/O operations but cannot currently throw IOException.
2. The 4-arg walkFileTree method has a maxDepth parameter but doesn't clearly specify the behavior when at maxDepth. In particular it does not specify how directories at maxDepth should be handled.
3. When following symbolic links then walkFileTree will detect and report cycles to the FileVisitor's visitFile method. On further analysis, and necessary once the spec issue with the maxDepth is addressed, cycles should instead be treated as errors and the visitFileFailed method invoked instead.
4. FileVisitOption.DETECT_LOOPS is no longer required. The FOLLOW_LINKS option requires that cycles be detected and reported.
5. For consistency reasons, the preVisitDirectory method should provide the directory attributes. This will also potentially help the performance of applications that require the directory attributes during iteration.
6. The preVisitDirectoryFailed method is surplus to requirements and forces developers to put error handling in this and the visitFileFailed method. On further examination, the API would be simpler if the preVisitDirectoryFailed is removed and the vistFileFailed method invoked for all cases where a file could not be visited.

EVALUATION See description.