[vcpkg] Add x-ignore-lock-failures

[strega-nil]

This should fix #14281 at least as a stopgap.

Additionally, adds better errors.

[BillyONeal]

Does this do the right thing? x-wait-for-lock is already off by default...

[BillyONeal]

(To clarify, I thought we only set --x-wait-for-lock in the msbuild integration pieces which should be unaffected by this NFS stuff since that's Windows?)

[strega-nil]

@BillyONeal yeah, disable-lock allows a user to just deal with "locking a file fails for a reason that isn't someone else owning the lock"

[BillyONeal]

@BillyONeal yeah, disable-lock allows a user to just deal with "locking a file fails for a reason that isn't someone else owning the lock"

That's not what this does though; it's making disable-lock unconditionally skip everything related to locking

[strega-nil]

yeah, exactly; if someone is dealing with "Weird Things", they can use this to disable the lock to just get things working.

[BillyONeal]

yeah, exactly; if someone is dealing with "Weird Things", they can use this to disable the lock to just get things working.

Why can't they just not pass --wait-for-lock then? That's what I meant by

(To clarify, I thought we only set --x-wait-for-lock in the msbuild integration pieces which should be unaffected by this NFS stuff since that's Windows?)

Can't we distinguish between "failed to take the lock because of an error" and "failed to take the lock because there's another vcpkg alive here"?

[strega-nil]

@BillyONeal yes, we can, that's why --wait-for-lock exists. The errors on the original thread were errors that weren't caused by another vcpkg. Are you asking if we should add a --allow-lock-to-fail or something?

[BillyONeal]

I'm saying that it is unclear here why instead of adding a switch that says "don't do X", we aren't just asking the user to not pass the switch that says "do X". If the user didn't pass --wait-for-lock, why are we treating any management of the lock as a fatal error?

[strega-nil]

@BillyONeal you need a lock in order to do anything? I'm confused where you're confused.

If you have a vcpkg install going, it needs to access the buildtrees and the like in a mutable way. Therefore, you need mutual exclusion. We do that via the lock file; if --x-wait-for-lock is passed, then we wait until the lock is free, else we try a few times and then print an error if we can't get the lock.

This solves an entirely different issue, which is where the lock isn't get-able for reasons that aren't "it's already taken".

[BillyONeal]

I discussed this with @strega-nil over IM and my confusion was because I was thinking the world was like this:

and so I was wondering why were adding a switch that just undid what another switch did. The actual effects post this PR are:

[BillyONeal]

This is "info:reviewed" but I'm not merging it because Nicole has the power to do that herself and might want further feedback from others on the team