Open a-sully opened 11 months ago
Only
SyncAccessHandle
can currently directly access the file. Some developers don't like sync APIs, so providing "exclusive-in-place" access viaFileSystemWritableFileStream
might look compelling from this point of view. "Abort" could only close the stream in that case indeed.
Right, "abort" would be a bit of a misnomer. But I think that's okay?
Another potential source of confusion might be that createWritable({ mode: "exclusive-in-place" })
would clear the file, since keepExistingData
defaults to false
. So most(?) developers using this presumably would want createWritable({ mode: "exclusive-in-place", keepExistingData: true })
... but I think that's okay, too? Changing the default only for this mode
seems even more likely to lead to confusion
Also, curious to hear thoughts on this issue from @annevk or @szewai
Right, "abort" would be a bit of a misnomer. But I think that's okay?
Yes, I think that's ok, just that the spec should probably mention that.
Another potential source of confusion might be that
createWritable({ mode: "exclusive-in-place" })
would clear the file, sincekeepExistingData
defaults tofalse
. So most(?) developers using this presumably would wantcreateWritable({ mode: "exclusive-in-place", keepExistingData: true })
... but I think that's okay, too? Changing the default only for thismode
seems even more likely to lead to confusion
Yeah, they would have to add "keepExistingData: true" too.
The proposal for a new locking scheme - intended primarily to address #34 - also proposes new modes of creating a writable file stream
Migrating the following conversation over from https://github.com/mozilla/standards-positions/issues/861 (cc @jesup)
@a-sully:
@janvarga: