Comments (7)
Yes, that's how blink implements file-backed Blobs/File objects. For the general case I don't really see a better option, but for fs-api backed blobs (i.e. the ones this spec deals with) I don't see any reason why we couldn't do better and rather than checking on every operation instead have any operation that modifies a file in the fs API effectively invalidate all Blob/File objects pointing to the file. The general file case needs to deal with external modifications to files, but for files in the fs API it should be fine to assume that there are no external modifications. w3c/FileAPI#154 was my partial attempt at some point to better define snapshot state etc (or at least lay the groundwork for enabling defining it better). I still hope to revisit that at some point, although I don't have any concrete timeline in mind.
from fs.
So "snapshot state" ("Set fâs snapshot state to the current state of entry.") indicates that the data returned may not reflect later changes to the file; implying a read-into-memory (or copy) operation when the snapshot state is created. Note that the definition of 'snapshot state' is somewhat vague and circular if you follow the links.
This is at odds with the comments in this issue and in the getFile definition.
from fs.
See the discussion in w3c/FileAPI#47. @saschanaz has been doing some work in this area and it seems rather hard to completely prevent a File
object from being readable after its backing file was modified on disk. For typical cases where the backing file's timestamp changes we can do it, but if that stays the change there's not really a way to do it.
from fs.
The wpt tests assume that using a blob after the original file has been removed will reject with NotFoundError; this isn't in the spec (and may not be always possible per above, and shouldn't be the case if my comment from June 15 is correct (that snapshot state implies the data is read or copied at creation time))
from fs.
Is this spec the right place for this discussion? I don't think anyone actually wants to create a copy of the file in getFile()
. I agree with the sentiment that "snapshot state" is somewhat misleading phrase, but the terminology is from the File API.
It seems to me like the updating the File API spec to better specify when a file becomes unreadable would allow this spec to just point to that?
from fs.
I think we need snapshot state to be fully defined. The File API says it's set to the "state" of the file on disk; this could be interpreted to mean the state including (all) the data on disk, or it could be something else, but it sounds like the entire state of the file (i.e. a copy). Later on talking about errors, it implies that it's snapshotting some type of metadata and returns errors if they don't match. I suspect they meant it to refer to some type of metadata, but what and how this would interact with the system is confusing.
Also, if the file changes it may well still be readable. Also we don't want to spec something that requires stat() before every operation just to check if the 'snapshot state' has changed...
from fs.
Also we don't want to spec something that requires stat() before every operation just to check if the 'snapshot state' has changed...
I'm not a WebKit/Blink expert, but when I last checked their File API behavior they seemed to check the timestamp (which does require stat()
) to detect the change. That's really unfortunate :(
from fs.
Related Issues (20)
- proposals/MultipleReadersWriters.md
- File and Directory Watch Functionality for the FileSystem API HOT 1
- Clarify behavior of `createWritable()` when the corresponding file does not exist HOT 1
- Add a `FileSystemHandle.create()` method to create self
- Define File's type better (getFile()) HOT 6
- Define the Bucket File System in terms of the Storage spec
- Why is WirteParams's data both optional and nullable?
- Editorial: string formatting
- Support locking of directory entries
- Require taking a lock to remove an entry HOT 1
- FYI: TPAC 2023 WICG breakout session
- Temporary directories/files HOT 2
- New Modes of Creating a FileSystemWritableFileStream HOT 3
- No explicit file lock release when `write()` throws an exception HOT 3
- Origin Private File System â identification of buckets (similarly to FAS API showSaveFilePicker) HOT 3
- Using F_FULLFSYNC for flush() causing slow performance on Mac HOT 1
- getFile() shouldn't require a copy of the underlying data HOT 5
- Add a FileSystemFileHandle copy method
- Hyuuhhh
- POSIX style path access for OPFS
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. đđđ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google â¤ď¸ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fs.