Specify unlink-file-at in terms of POSIX.

[wingo]

Unfortunately only MacOS has the POSIX behavior of returning EPERM when unlinking a directory; Linux returns EISDIR, and Windows returns EACCESS. Because EACCESS may arise for other reasons but which are outside the purview of WASI, we map all EACCESS to EPERM.

[badeend]

If all major OS flavors return something different, then clearly POSIX is not the authoritative source here. Additionally, the page you referenced includes the footnote:

The standard developers reviewed TR 24715-2006 and noted that LSB-conforming implementations may return [EISDIR] instead of [EPERM] when unlinking a directory.

I personally don't see anything wrong with Linux' behavior of returning EISDIR; it is more to-the-point and precisely describes why it failed, instead of a catch-all EPERM.

[wingo]

Ah, thank you for that footnote, I missed it! And I do like Linux's return code! But if we want one semantics, EISDIR isn't it, as we can't translate results from other platforms without races.

Another option would be to relax WASI to allow but not require is-directory.

[badeend]

if we want one semantics

As a general piece of advice: I'd keep away from trying to synthesize a single semantic model for "filesystems" in general. Each OS works differently, and even within a single OS, different filesystem implementations (NTFS, FAT32, EXT4, ..) can produce different results.

Another option would be to relax WASI to allow but not require is-directory

That sounds like a good solution to me. 👍

[vados-cosmonic]

Hey @wingo thanks for this contribution and the discussion -- would you be open to making the note even more specific?

If we're going to note that there are some discrepancies we might as well be specific about which platforms do what to prevent confusion down the line, until this is fixed/not the case.

Another option would be to relax WASI to allow but not require is-directory.

Are you up for contributing this? This sounds like the right solution (regardless of whether this PR is merged in the meantime). If we go in this direction then the note should actually be more specific (looks like in any case it should be more specific), and it will be up to implementers to follow the semantics (or choose to return error-code::is-directory)