getFile() shouldn't require a copy of the underlying data about fs HOT 4 OPEN

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...

from fs.

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.

from fs.

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.

from fs.

That sounds right. That is a good argument for attempting to find a better fix.

from fs.