Skip to content

path/filepath, io/fs: undocumented behavior in WalkDir about the second call reporting the readdir failure #51617

@liuycsd

Description

@liuycsd

With the new WalkDir API, if the readdir fails, the walkDirFn will be called for a second time, with the readdir error.

The doc says

// The error result returned by the function controls how Walk continues.
// If the function returns the special value SkipDir, Walk skips the
// current directory (path if info.IsDir() is true, otherwise path's
// parent directory). Otherwise, if the function returns a non-nil error,
// Walk stops entirely and returns that error.

If the walkDirFn do return a SkipDir for this second call, it would be returned(

dirs, err := readDir(path)
if err != nil {
// Second call, to report ReadDir error.
err = walkDirFn(path, d, err)
if err != nil {
return err
}
}
) to the outer loop and break(
for _, d1 := range dirs {
path1 := Join(path, d1.Name())
if err := walkDir(path1, d1, walkDirFn); err != nil {
if err == SkipDir {
break
}
return err
}
}
) it. So it would not cause Walk to stop walking the entire tree and not only skips the current directory, but also skips path's parent directory even though info.IsDir() is true.

And the doc also says

// The err argument reports an error related to path, signaling that Walk
// will not walk into that directory.

But there is a way letting it walk into the possible partial dentry list by returning nil from the walkDirFn.

These behaviors are different from the Walk func. Is it intentional for them to work like this? If it is, it would be better to have them documented out.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions