getFile() shouldn't require a copy of the underlying data
annevk opened this issue · 5 comments
What is the issue with the File System Standard?
This might be shortcoming with the File API, but surely https://fs.spec.whatwg.org/#dom-filesystemfilehandle-getfile shouldn't actually copy the underlying data? It should just be a pointer.
If it is a copy or a pointer should be unobservable, as long as the "snapshot state" behavior is such that if the file changes the File object becomes unreadable (which I think is the only reasonable behavior).
But yes, the File API spec is missing the necessary hooks to properly specify this snapshotting behavior (which doesn't just effect this spec, but also things like IndexedDB). It is still somewhere down on my todo list to try to fix that...
The concept of "snapshot state" also has some fraught edge cases if I remember correctly as it's not something file systems offer, but I agree that it's overall not a big issue. At least in practice.
I think I may be experiencing one of these edge cases, which results in different behavior depending on the operating system.
Some context: I'm using getFile() to read a file called status.txt on an Accu-chek Smart Pix reader. This is a device that talks to a glucose meter, and when it gets data from the glucose meter, it updates status.txt. On Linux, when status.txt changes, I see the changes when I call getFile(). On Windows and MacOS, it still shows the stale data.
I suspect this may be because lastModified changes on Linux, but not on Windows or MacOS.
That sounds right. That is a good argument for attempting to find a better fix.
It sounds like we’re talking about copy-on-write — wouldn’t this rely on the existence of something like a mutation event system (e.g. the one described in #123)?