Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

web-platform tests don't match the spec (errors, '.', '..') #26

Open
jesup opened this issue May 23, 2022 · 1 comment
Open

web-platform tests don't match the spec (errors, '.', '..') #26

jesup opened this issue May 23, 2022 · 1 comment

Comments

@jesup
Copy link
Contributor

jesup commented May 23, 2022

There are quite a few differences between the web-platform tests and the current spec -- which isn't really surprising, since the spec is still being modified. Some error conditions disagree, I think. There are also tests for move() support, which isn't in the spec.

There also are extensive tests for '.' and '..', and inherent assumptions that both are automatically defined when a directory is created, but that isn't really in the spec (perhaps it's vaguely alluded to by saying filenames are platform dependent, but that's very weak -- and as we discussed, it would be nice to see that go away). The spec needs to be more precise about what the filesystem tree navigation should look like. (Probably it helps use by wasm programs if '.' and '..' are automatically defined when a directory is created, I presume)

@jesup jesup changed the title web-platform tests don't match the spec (Transferable, errors, '.', '..') web-platform tests don't match the spec (errors, '.', '..') May 23, 2022
@dslee414
Copy link
Collaborator

Looks like there have been recent changes in WPT and spec, which would cover move() and error types, mentioned here.

In regards to '.' and '..', and that both are automatically defined -- could you explain more about what you mean here?
I see that there is WPT for checking '.' and '..' as an invalid file name (as currently mentioned in the spec), but not sure what you mean by "inherent assumptions"

Whether we should allow '.' and '..' as valid file name, that's a good question, and somewhat related to #38 -- perhaps we can discuss that more there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants