The WPT tests seem to assume you must pass 'at', and if you don't all reads start at 0. This is ... odd, especially for implementing the equivalent to read(), which maintains an internal position in the file, and reads from there. It means for almost all reads (or writes), you must pass at, which means you must track the expected position in the file - likely in a wrapper around syncaccesshandle.read()/write(). Emscriptem certainly can track the location in the file and insert at:nnnn always, but this seems like an odd choice for an API (and not great for performance, due to the extra parsing and validation and the basically forced extra kernel call to seek -- we could avoid the seek() call if we also track the position and elide if if it's a no-op, but that's not worth it either).
I imagine this is legacy decisions from the non-OPFS File System API
Though maybe not legacy -- SyncAccessHandles came later. Can (should?) we change this? If you're writing a bunch of data, it's a whole lot more (unnecessary) bookkeeping and overhead.
position += handle.write(data1, {at: position});
position += handle.write(data2, {at: position});
But you can't quite do that, since if there's an error and a partial write, you won't notice it. To be pedantic about catching errors, you need to do:
try {
written = handle.write(data1, {at: position});
if (written != data1.length()) { /* error */} else { postion += written;}
written = handle.write(data2, {at: position});
if (written != data2.length()) { /* error */} else { postion += written;}
} catch(e) { ... }
With classic posix-like read/write (with an assumed position update), it would be
handle.write(data1);
handle.write(data2);
or
try {
if (handle.write(data1) != data1.length) { /* error */}
if (handle.write(data2) != data2.length) { /* error */}
} catch(e) { ... }
The WPT tests seem to assume you must pass 'at', and if you don't all reads start at 0. This is ... odd, especially for implementing the equivalent to read(), which maintains an internal position in the file, and reads from there. It means for almost all reads (or writes), you must pass at, which means you must track the expected position in the file - likely in a wrapper around syncaccesshandle.read()/write(). Emscriptem certainly can track the location in the file and insert at:nnnn always, but this seems like an odd choice for an API (and not great for performance, due to the extra parsing and validation and the basically forced extra kernel call to seek -- we could avoid the seek() call if we also track the position and elide if if it's a no-op, but that's not worth it either).
I imagine this is legacy decisions from the non-OPFS File System API
Though maybe not legacy -- SyncAccessHandles came later. Can (should?) we change this? If you're writing a bunch of data, it's a whole lot more (unnecessary) bookkeeping and overhead.
But you can't quite do that, since if there's an error and a partial write, you won't notice it. To be pedantic about catching errors, you need to do:
With classic posix-like read/write (with an assumed position update), it would be
or