One very painful lesson-learned that I have gathered from a great many programming / operating-system environments is that, especially if you intend to alter the filesystem structure, you should: “iterate first, and act second.” Any sort of change to the filesystem topology can be very disruptive to a “walker” ... and even-slightly-deep nested directory structures can utterly-bamfoozle many, say... “hidden, operating-system imposed” limits.
What I customarily try to do is to walk through some reasonable subset of the territory that is “downstream of” wherever-it-is that I started, accumulating along the way a list of “the completely-qualified filenames of something that I’ve decided I want to act upon,” and, separately, a list of “(more) places I want to get to soon.” I completely run-thorough that walk first, then switch gears and act upon the files. Having completed that task, I switch back to exploring more locations, popping entries off of the “to-do” list and silently ignoring any that are no longer there.
This approach enables the filesystem-walker to traverse over a structure that can be relied-upon not to change (not by my hand, anyway ...), and it generally works quite well.
In reply to Re: A warning about passing mountpoints as arguments to directory recursion programmes
in thread A warning about passing mountpoints as arguments to directory recursion programmes by Don Coyote