I'm slightly worried that since these error codes are provided by the filesystem driver, there might be an infinite amount of them. What if another filesystem driver we've not yet seen fails this question in a different way, like with ERROR_INVALID_ARGUMENT or something? Is it reasonable to log a non-fatal error somewhere and continue with the "not a reparse point" case for all errors?

@DHowett An alternative could be ignoring any error and return null but I think it is not good practice to hide errors which we do not know.

Test confirmation #13605 (comment)

Hmm. While ignoring errors from this check may not be the best idea, the purpose of this check is just to verify if the path is a reparse point, right? So if it errors out, it might be OK to assume it's probably not and log the error the driver reports somewhere without outright failing the overall cmdlet operation?

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

It sounds like we're not yet resolved on the right course of action for this PR. It feels to me like we need to be tolerant of errors at this level, but let the information that some error has occurred bubble up to the user in some way.

Writing to the error stream would be misleading, if the actual intended action didn't fail. But if we experience a real failure, how will we know? Perhaps a real failure will surface in a later error, but we can ensure that this earlier failure is recorded somewhere.

Is there anywhere we could consistently log that cross-platform, or is the warning stream a better place perhaps?

I agree that we can ignore the error in main code path but my concern is that we lost information in the problematic area (PowerShell does not work well with reparse points.).
We could add the information (check on reparse point) in tracing. Thoughts?

We could add the information (check on reparse point) in tracing

As in showing it in Trace-Command? Is there also another more prominent place we could add it?

I don't think it makes sense to somehow inform the user about this situation. It only makes sense if something goes wrong - user does not get expected result. In this case, tracing will help.

It only makes sense if something goes wrong - user does not get expected result.

Right. The question is, how reliably does PowerShell know if something goes wrong?

If possible I'd prefer this not to be a subtle behaviour that people are forced to use a trace to unravel. I suspect many users would be mystified by it, not use a trace, and either give up or open an issue, where they'll tell us that we should be throwing an error.

Rather, we can include it in the trace, but if we end up throwing an error at the end of the action, it might be nice to include the information from the reparse point processing.

We know that the scenario works well without the exception. Only concern is there is a scenario where it could not work because reparse point is generic and sometimes unpredictable from our experience. For diagnostic we have to use a debugger that could be complex but we could use more simple tracing as in other code paths in the file system provider.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

I tried to do minimal changes but after looking more I think the original code confuses and we should simplify it - fast return if we can not read a reparse point and it doesn't matter for whatever reason it happens - it is not a reparse point or the file system doesn't support reparse points or something else.

Is there the possibility of adding a log or trace before we return null?

@rjmholt I think now it makes no sense. Before the fix we have a tricky code paths which made us think that there were unpredictable scenarios. In fact, the source code contained an error because it allowed handling an uninitialized structure (after lastError == ERROR_NOT_A_REPARSE_POINT we go to switch).

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

Looks like you can't execute native commands in WinPE w/o this fix

@PoshChan please remind me in 5 days

@rjmholt, this is the reminder you requested 5 days ago

🎉v7.2.0-preview.2 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes

🎉v7.1.1 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes