I believe the current "check_chown" could be passed by a no-op (since the file will be owned by the current user even *before* the call to chowntree). Testing this properly is actually rather difficult (since the only uid and gid we can rely on are those of the current process).

More significantly, I don't agree with the proposed error handling (i.e. attempting to roll back to the original state). Instead, I think it would be more appropriate to follow the rmtree ignore_errors/onerror style so that uses can either unconditionally ignore errors (including dir listing errors) or else tailor the error handling themselves. Any custom error handling should also cover the actual chown operation, not just directory listing errors inside os.walk.

I think, like walkdir itself, there's enough under the hood here that the idea requires some baking time outside the standard library. How do you feel about migrating this discussion over to the walkdir issue tracker as a higher level API proposal there? (https://bitbucket.org/ncoghlan/walkdir/issues).

I had a couple of other minor comments, although they're largely irrelevant given the more significant comments above:

There's a gratuitous inconsistency in the type-checking for uid/gid (one uses "isinstance(uid, str)", the other "not isinstance(gid, int)". Neither is a particular good check for the "None, integer or string" case anyway. It would be better to just try the following in order:

- "is None"
- operator.index
- _get_uid/gid (as appropriate)

The dict initialisation and error handler definition may as well move inside the if statement.