annevk
commented
1 year ago 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.
As part of the changes for #96, the
FileSystemFileHandle.createWritable()algorithm now specifies aNotFoundErrorpromise rejection if the file corresponding to theFileSystemFileHandledoes not exist. See https://fs.spec.whatwg.org/#dom-filesystemfilehandle-createwritableUnfortunately, 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 aNotFoundErrorif 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 thekeepExistingData: falsebehavior to re-create a file may break.Notably,
remove()self was only recently shipped on Chromium browsers (and the spec PR https://github.com/whatwg/fs/pull/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 https://github.com/whatwg/fs/issues/59#issuecomment-1404676261) an explicit
create()method (see #126) rather than relying on a quirk ofcreateWritable()to perform "create self" on a file handle. Barring any objections, I think we should converge on "createWritable()will always reject with aNotFoundErrorif 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)