jvff / gradle Goto Github PK

The doVisit() method keeps track of the relative path in a LinkedList and uses an integer to track the segment index. Because integers aren't stored in the heap (they are immutable), it can't be stored as a final method variable to be used in the SymlinkAwareFileVisitor anonymous class instance. The workaround used was to simply use the relative path list size, but this might not be optimal.

Need to see if this is necessary. If so, one solution would be to add a method overload for visitTreeOrBackingFile(SymlinkAwareFileVisitor) and then update AbstractFileTree and CompositeFileTree.

Do both really treat them as normal files?

Jdk7DirectoryWalker by default follows all links. Need to see if this behaviour should be kept, and then make all implementations that have both a visit(FileVisitor) and a visit(SymlinkAwareFileVisitor) methods consistent.

Some classes use NIO to detect if a File is a symbolic link or not, maybe this should use a FileSystem instance instead to not be dependent on Java 7.

Classes:

• AbstractFileTreeElement
• DefaultFileTreeElement
• DefaultDirectoryWalker
• DirectoryFileTree
• SingletonFileTree
• SingleIncludePatternFileTree

An example is a Tar file. It is read as a stream, and the stream file entries can be symbolic links. When visiting, the file entries are visited in the stream order. The problem arises when a symbolic link is read and the symbolic link strategy is set to follow. A couple of situations can appear:

1. The symlink references a file that has already been visited
2. The symlink references a file that will be visited in the future
3. The symlink potentially references a file not the archive
   1. The refereced path is relative
   2. The referenced path is absolute (e.g., link to a system file)

Need to consider how to handle these situations.

If a symlink is traversed twice, stop traversal. Handling what to do next is an open question. Treat it as a normal file? Ignore it? Fail?