Clarify behavior of `createWritable()` when the corresponding file does not exist

[a-sully]

As part of the changes for #96, the FileSystemFileHandle.createWritable() algorithm now specifies a NotFoundError promise rejection if the file corresponding to the FileSystemFileHandle does not exist. See https://fs.spec.whatwg.org/#dom-filesystemfilehandle-createwritable

Unfortunately, this does not match the behavior that has been implemented in Chromium browsers for a quite long time; specifically that

• createWritable({ keepExistingData: true }) fails if the file does not exist, since there is no existing data to copy to the swap file (has no wpt, notably)
• createWritable({ keepExistingData: false }) succeeds if the file does not exist, since there is no existing data to copy (WPT: https://github.com/web-platform-tests/wpt/blob/7690497bf37a4ecb28cf2cfef5e611c91882e76d/fs/script-tests/FileSystemDirectoryHandle-removeEntry.js#L125-L135)
• createWritable()always rejects with a NotFoundError if the parent directory does not exist (WPT: https://github.com/web-platform-tests/wpt/blob/7690497bf37a4ecb28cf2cfef5e611c91882e76d/fs/script-tests/FileSystemWritableFileStream.js#L27-L34)

Which... is a bit of an odd state to be in anyways. It seems that this was a quirk of the Chromium implementation rather than an intentional choice of behavior. If we had a WPT covering the first case, this likely would have been noticed sooner

One quirk of this behavior is that, since there does not exist an explicit way to "create self" given a file handle, createWritable({ keepExistingData: false }) can be used to "create self" after a handle was removed (while no such workaround exists for a directory handle). This means that sites which relied on the keepExistingData: false behavior to re-create a file may break.

Notably, remove() self was only recently shipped on Chromium browsers (and the spec PR #9 has been blocked on unrelated changes for a while), so the chances of breakage is likely low.

Personally, I would prefer (and it was indicated in previous discussions that @szewai might prefer #59 (comment)) an explicit create() method (see #126) rather than relying on a quirk of createWritable() to perform "create self" on a file handle. Barring any objections, I think we should converge on "createWritable() will always reject with a NotFoundError if the underlying file does not exist", then add WPTs to assert this behavior and perhaps add a warning in the spec of the behavior change on Chromium browsers. Thoughts? (FYI @annevk @jesup @szewai)

[annevk]

Sounds good, except I don't think we should add a warning in the specification. Ideally what we write can last a long long time. Gotchas are more the domain for MDN, CanIUse, and web-developer-facing articles.