Closed Deedasmi closed 7 years ago
Could you say more about why you might find that more useful than just creating a new iterator for each path?
The primary concern is duplication. I'm scanning user-defined directories for files that have a last_modified date different from the recorded last_modified date. The resulting action does not modify the file, but should only happen once per file.
The solution would be chaining an arbitrary number of iterators together, sorting/de-duplicating (or dumping into a hashset and recovering), and then filtering by last_modified.
It seemed like a reasonable use case for the library, so I figured I'd suggest it.
Oh, whoa, I misread your initial comment. It seems like you want walkdir to be able to accept an arbitrary list of file paths and guarantee that every path is visited exactly once.
That's definitely way outside the domain this library, as that would require quite a bit of extra overhead for keeping track of the required state. This library also does this in a very limited case for symbolic links, but it checks for duplicates only by examining the current stack, which cannot generalize to your use case.
It sounds like this is something that should be built on top of walkdir
.
I think it would be useful if WalkDir could take multiple Paths and build a single iterator containing every file and folder once.
E.x.