Sorry, I have no minimal test case. I can only try to explain what goes
on: IIUC the tree can contain so called Stub items. These represent
"holes" in the tree where we should expect a file or a subtree, but the
irem has not yet been read from disc. This is an optimization which
allows us to operate on parts of a tree without reading all of it in
memory. The findFile function returns Nothing id it hits a Stub. So what
we do is to expand everything in the tree which lies on the given path
(replacing Stubs with what is actually there).
In order to create a minimal example, one would need to find out which
of the hashed-storage functions called here create such a "partially
evaluated" tree (i.e. one with stubs in it) and study which
side-conditions exactly trigger this optimization.
|