-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporary directories/files #145
Comments
Would Storage Buckets address this use case? The current implementation only works with IndexedDB, but the eventual plan is to enable it for other storage methods as well. |
Plausibly, though from reading the explainer it seems that deletion is still in general lazy, i.e. when disk storage becomes high. Like if I do the following: class Archive {
static async create() {
const bucketId = crypto.randomUUID();
const bucket = navigator.storageBuckets.open(this.#bucketId, { persistent: false });
return new Archive(bucketId, bucket);
}
constructor(bucketId, bucket) {
this.#bucketId = bucketId;
this.#bucket = bucket;
}
addFile(fileName, blobSource) {
const rootDir = await this.#bucket.getDirectory();
const filesDir = await rootDir.getDirectoryHandle("files", { create: true });
// add file to files dir
}
async encode() {
const dir = await this.#bucket.getDirectory();
const archive = await dir.getFileHandle("archive.ext", { create: true });
// encode things to the archive
return archive;
}
async dispose() {
await navigator.storageBuckets.delete(this.#bucketId);
}
} and create an archive, and close the page before From the issues on storage buckets it seems like session buckets is probably the most appropriate place for this, so I'll close this issue. |
NOTE: This issue is not a request for access to the user's tempory directory/files.
So the file system APIs are fairly convenient for writing files, however at present all files/directories are either persistent or not regardless of need.
For use cases like reading/writing large archives, it would be desirable to be able to have temporary files/directories that can be written like other files but are automatically collected when no references remain.
Strawman API
Alternatives considered
OPFS +
beforeunload
- This is this only available on the main thread which makes it inconvenient for use in workersOPFS +
FinalizationRegistry
on wrapper objects - Finalization of objects is not guaranteed to occur at all so can't be reliably used to dispose of file-system-handlesBoth approaches don't work either if
.terminate()
is called on a worker as there would be no opportunity for the worker to perform cleanup.The text was updated successfully, but these errors were encountered: