Note: What is referred to as the "local file system" in this spec, does not have to strictly refer to the file system on the local device.
So basically a browser can implement this using a KV-Database or similar, nothing requires the browser to actually allow you to (file picker) "pick" files in your home directory or similar especially given that:
Note: While user agents will typically implement this by persisting the contents of this origin private file system to disk, it is not intended that the contents are easily user accessible. Similarly there is no expectation that files or directories with names matching the names of children of the origin private file system exist.
Also
The origin private file system is a storage endpoint whose identifier is "fileSystem", types are « "local" », and quota is null.
So this "file system" might exist in a complete "parallel universe" to your normal file system.
Also given that this is not a new storage type it means that if you browser is setup to e.g. clear local storage from a specific origin if that origin wasn't used for a month this might still apply.
So have fun with you "files" having disappeared after some longer holidays (e.g. on Safari, at least the way Apple planed to implement it a while ago).
So while it looks like a file system access API, it might end up not being on depending on browser implementation details.
Also any access goes through a file picker and you can't ".."-navigate up this avoid many problems with security, adding in no file links no fancy operations etc. means this should not be a problem even even if it allows access to you files.
Through in the end it depends a lot on the choice the browser does when implementing it.
The origin file system is pretty pointless, but it is only one part of the spec. It is definitely intended that the local file system (whether a cloud k/v store or not) at least allows for moving data between completely different websites.
I think you make a good point about Safari's nonsense with browser data. The spec should require implementors to never clear out what they use for "local file system" unless the user explicitly says to, and only for the files selected for deletion. The old APIs like local storage/IndexedDB unfortunately assumed no browser vendor would be as dumb as Safari with their ridiculously short retention policy.
Similar the limitations, especially the absence of flush makes it kinda useless to run a database in the browser :(
Through there is `persist` on the storage manager, but I'm not sure how much this helps. Theoretically it could work like fsync or F_FULLSYNC, but practically I'm not sure at all.
You can likely assume fsync is going on once you close a file writer. It's already a super expensive operation, so there would be little reason not to sync. The expensive part is they copy the entirety of the old file to a temp file, let you do changes to the temp file, then copy the temp file to the old file on close.
The implementation creates other problems for DBs though since you can't really do small writes efficiently. One idea I've had would be to implement a virtual paging system, but then you introduce a new layer of abstraction and it's still going to be really slow on NTFS (since it assumes a few large files, not many small ones).
Comments
The gotcha is this (quote):
So basically a browser can implement this using a KV-Database or similar, nothing requires the browser to actually allow you to (file picker) "pick" files in your home directory or similar especially given that:
Also
So this "file system" might exist in a complete "parallel universe" to your normal file system.
Also given that this is not a new storage type it means that if you browser is setup to e.g. clear local storage from a specific origin if that origin wasn't used for a month this might still apply.
So have fun with you "files" having disappeared after some longer holidays (e.g. on Safari, at least the way Apple planed to implement it a while ago).
So while it looks like a file system access API, it might end up not being on depending on browser implementation details.
Also any access goes through a file picker and you can't ".."-navigate up this avoid many problems with security, adding in no file links no fancy operations etc. means this should not be a problem even even if it allows access to you files.
Through in the end it depends a lot on the choice the browser does when implementing it.
The origin file system is pretty pointless, but it is only one part of the spec. It is definitely intended that the local file system (whether a cloud k/v store or not) at least allows for moving data between completely different websites.
I think you make a good point about Safari's nonsense with browser data. The spec should require implementors to never clear out what they use for "local file system" unless the user explicitly says to, and only for the files selected for deletion. The old APIs like local storage/IndexedDB unfortunately assumed no browser vendor would be as dumb as Safari with their ridiculously short retention policy.
Similar the limitations, especially the absence of flush makes it kinda useless to run a database in the browser :(
Through there is `persist` on the storage manager, but I'm not sure how much this helps. Theoretically it could work like fsync or F_FULLSYNC, but practically I'm not sure at all.
You can likely assume fsync is going on once you close a file writer. It's already a super expensive operation, so there would be little reason not to sync. The expensive part is they copy the entirety of the old file to a temp file, let you do changes to the temp file, then copy the temp file to the old file on close.
The implementation creates other problems for DBs though since you can't really do small writes efficiently. One idea I've had would be to implement a virtual paging system, but then you introduce a new layer of abstraction and it's still going to be really slow on NTFS (since it assumes a few large files, not many small ones).