mount: some refactor and improved GoDoc about Windows support

[thaJeztah]

Commit 0c569e0 (#26) added a fast-path for Linux, but inadvertendly changed the behavior on Windows, which previously handled RecursiveUnmount() as a no-op, and now panicked.

This patch makes RecursiveUnmount() a no-op again on Windows.

[Kir: fixed commit/PR reference]

[thaJeztah]

Relates to moby/moby#41458 (comment)

ping @kolyshkin @cpuguy83 PTAL

[kolyshkin]

Thanks! Is it possible to add some CI job to prevent this kinds of mishap in the future?

[kolyshkin]

It looks like Unmount() and RecursiveUnmount() should behave in a similar way. Currently, they both panic on Windows, and it makes sense to me, as they should not be called on Windows. This commit makes them behave differently.

Perhaps we can make both no-op? This will

• make this patch much smaller;
• make the behavior consistent between the two.

[thaJeztah]

@kolyshkin updated, but I noticed that before 0c569e0, Unmount() already produced a panic on Windows, so I'm a bit on the fence on updating.

Actually thinking now if we should accept the breaking change and update downstream code or not 🤔 (the package is still pre v1.0, so from that perspective, it should be ok)

[kolyshkin]

If you can just change unmountBare (and unmount) for Windows to return nil that will have the same effect with much smaller set of changes needed.

Yet we need to decide first whether we want them both to be no-op or panic. I don't have a strong preference but would like to hear other opinions.

[kolyshkin]

moby/moby#41458 (comment) it seems that the panic behavior is better than no-op. In these two cases, it clearly tells the test is not working (and it should not work on Windows).

So, I'm in favor of panic.

[thaJeztah]

So, alternatively, I guess we could not implement at all on Windows (move this to a _linux.go or _unix.go wdyt?

[kolyshkin]

Yeah, I think the rename + build flags will be slightly cleaner.

[kolyshkin]

What I'd like to see here is a minimal patch. Moving lots of code around makes it harder to dig through git history, and unless there is a good reason to, I'd rather not do it.

Maybe I'm wrong and this is unavoidable.

[thaJeztah]

The situation currently is that we have separate files for platform-specific implementations, but there's code in files that doesn't work on the platform it's enabled on.

So, yes, I agree that a smaller diff would be good, but it looks like code is in the wrong files.

[thaJeztah]

I see @kolyshkin preferred "Yeah, I think the rename + build flags will be slightly cleaner."; let me have a look what that looks like.

[thaJeztah]

@kolyshkin pushed a commit with those changes; if you think this looks good, I'll squash

[kolyshkin]

LGTM