Tested on Linux without access to either file or directory.

The obvious problem with this is silence. With the current code it breaks loudly, but with the fix, it continues and only logs the issue in the container's log since this is prior to context init. If that presents problems, we'll probably have to add more options but I'd rather not complicate it without justification.

I replaced the logic and committed to both branches but will have to leave open for testing, as this is very difficult to reproduce outside of a real install. Once I can update my dev instance to a snapshot of this I can exercise it.

Files.walkFileTree does the right thing, via a FileVisitor implementation that includes explicit calls into the visitor when entering a directory that can’t be opened, so the exception gets passed and can be logged and ignored, so that’s the solution. A rewrite, as I assumed.

So, I don’t see a fix of the sort one would want. The tree walk methods all return a lazy Stream, and it’s only while fetching items from the Stream that it notices the access exception and then it throws that unchecked, so catching it would abort the whole process, rendering it useless.

And as it is, the values returned are already being filtered heavily and not returning any directories, so I don’t see how I can change the BiPredicate in a way that would prevent it trying to access them even if I knew the names to omit.

It just seems to be an inherent flaw in the way they implemented it. I will have to see if they have a similar search method somewhere that doesn’t return a Stream or calls some object/method with a “visit node” kind of approach so that the exception might be trappable by the visiting code.

Unit test confirms it’s in that line but the stream is just a deferred processing model, so it must be executing the tree walk actually later during that line, which is what I suspected.