I rebased the change upon the new revision of #46.

This looks good to me. In particular, the interpretation of MTIM vs MTIM_NOW and so on looks reasonable. It looks compatible with WASI libc, and in general rejecting unimportant variations in usage will make things more consistent.

Would you mind adding a test for this to wasi-misc-tests?

I'll add a test.

Can we change the spec to be explicit about the MTIM vs MTIM_NOW interpretation and close #53 (I probably should've raised the issue against wasmtime, not wasi-common)

Yeah. Actually, the best place to file #53 is the WASI issue tracker, tagged with wasi-filesystem.

Sounds good. And this just needs a few conflicts resolved before we can merge it.

@marmistrz could you fix conflicts please?

This still needs some work to pass the new test.

It's really interesting that it fails on *nixes and not Windows :-)

Because I haven't enabled them yet on Windows :P

Haha, touche! Totally forgot about that! :-D Lemme know if you need any help with debugging or whatnot!

The reason why CI on Mac fails is that on Mac filetime uses utimes and not utimensat. The former has microsecond precision, the latter - nanosecond. https://github.com/alexcrichton/filetime/blob/master/src/unix/mod.rs#L6-L23

@alexcrichton is there any reason why we can't use utimensat on Mac? The previous implementation in wasi-common used utimensat and passed the CI. utimensat should be available starting from MacOS 10.13.

@marmistrz do you want me try filetime out on macos with utimensat used instead of utimes? If it passes, we could submit a PR with a fix to @alexcrichton's repo.

@alexcrichton, together with @marmistrz we've worked out that @marmistrz's changes build and test out fine with alexcrichton/filetime#43 patch applied. Could you have a look and let me know what changes should be made to that PR so that we could merge it in, etc.?