I'm using WalkDir and eventually hitting a directory that is an error. I know how to recover from that error so that WalkDir can continue into it, but I'm not sure how to tell WalkDir how to do that.
If the entry the Iterator yeilds is an error, then how can I implement logic to tell it how to recover?
Just call next on the iterator.
It might to help to show your code. What have you tried? What did it output? What did you want it to output?
Unfortunately, the code is proprietary, but if needed I can rewrite it as an example.
I guess I'm mainly not sure how calling next would solve that. At the point I'm at, I'm already iterating over the entries. At some point I call next and I get an entry that is an error on a directory saying the directory doesn't exist. At that point, if WalkDir thinks it doesn't exist I'm not sure how it could continue to iterate over files inside that directory.
The thing is, the directory does exist. I just need to tell WalkDir to look somewhere else then continue down that different path instead of the original directory path.
Well, that's pretty crucial information! I mean, literally speaking, if WalkDir can't read the directory entries because of an error, then there's nothing more it can do. Calling next skips over that directory and moves on to whatever is next.
There is no hook to override that behavior. If you have some special circumstance where reading a directory's entries errors but you instead need to look in some other place, then you either need to implement your own recursive directory traversal or create a new WalkDir iterator for the directory at whatever location. Then you'd need to somehow combine it with the original iterator. Maybe use a stack of iterators?
Okay, I'll look into that.
The specific issue is long paths on Windows. Some subdirectories have paths that are too long for Windows to handle, so even though they exist, WalkDir produces a "file does not exist" error. This is something which could be handled by adding a prefix to the path like \\?\ or \\?\UNC\ for UNC paths and trying again.
The problem for me which I think I'll run into is that the ordering is important before I iterate, so I'd need to preserve the same order it would be otherwise.
I'll see if I can come up with a way to do that by creating a new Iterator. Thanks!
Yeah, there's an open bug for file paths that are too long: "File name too long" error at 4096 bytes · Issue #23 · BurntSushi/walkdir · GitHub
Although, that's somewhat Unix specific. Windows has a more severe limitation (256 bytes, IIRC) and its fix is different from Unix.
Unfortunately, both are a bit difficult to fix in the context of a general library. Although maybe there is an easy fix for walkdir. Not sure.
walkdir does depth first traversal. So if you use a stack of iterators, I think you'll preserve the order walkdir would have originally given you.
Irrelevant nitpick: Windows' MAX_PATH is 260 UTF-16 code units and includes the terminating null. Basically the actual path is 256 but there is three extra characters for the DOS Drive (e.g. C:\).
The usual way to handle longer paths is to either:
longPathAware Application Manifest option. This is only available since Windows 10, version 1607 and also requires a registry key to be set. But this may be more feasible if you have full control of the environment.