The exact error codes used for particular situations are host-dependent

[CraftSpider]

Currently, the error code returned by an I/O operation is based on what that operation returns on the host, not the emulated target, system. The codes are translated to the target, but it is done through ErrorKind, so if the host returns ErrorKind::PermissionDenied, we will generate the equivalent error code on the target, whether or not the function could ever return that code natively.
This has always been true, but the recent work to support file I/O on Windows exposes it more obviously.

As a concrete example:
On Windows, writing to a read-only file results in ERROR_ACCESS_DENIED, which becomes ErrorKind::PermissionDenied.
On Linux, is results in EBADF, which becomes ErrorKind::Uncategorized.
No matter the emulation target, if running on a Windows host the write in user code will return PermissionDenied, and running on linux it will return Uncategorized.

There are a couple options:

• Attempt to match errors to the target OS
  • This would involve quite a bit of code, that would have to compare the operation, and current host system, and the target system. It would also be impossible sometimes - not all targets provide the same level of error granularity for some operations.
  • This would be N^M over number of supported hosts to number of supported targets, though many targets may de-duplicate.
  • It would also require a developer have access to relevant host systems - most notably, any new unix shim would need someone familiar with Windows to assist in creating the mapping, and vice versa.
• Forbid I/O on emulated targets
  • This doesn't seem like a good idea, but I mention it for completeness.
  • Would likely lead to a lot of 'I disabled isolation, why isn't fs working?'
• Accept this as a limitation of our emulation.
  • May lead to confusion when testing cfg(windows) code on a unix platform, or the reverse
  • Most non-cfg code shouldn't have issues - if this breaks that case, it was already broken when running on that platform

[CraftSpider]

Reference: #4371 (comment)

[RalfJung]

Currently, the ErrorKind returned by an I/O operation is based on what that operation returns on the host, not the emulated target, system.

It's based on both. Like, if you are on a Windows host and run a Linux target, we do generate actual Linux error codes, we don't just forward Windows codes. ErrorKind is not part of the API we implement, only the error codes we return actually matter.

However, this translation goes via ErrorKind, so if Windows says something that translates to InvalidInput but Linux would return something that translates to InvalidData, then we'll not behave like native execution.

Would be good if you could update the issue description, it is somewhat confusing right now. I think you had a concrete example?

---

I think for now this is not-a-bug. It would be a monstrous effort to even record the information of which exact error code is returned in which exact situation. We'd probably spend more code on that than on the rest of the shims. We'd never be done.

[CraftSpider]

Tried to elaborate on the exact issue, and added the example I encountered. If you have a better phrasing feel free to edit it further.