Skip to content
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

Closed
Jamesernator opened this issue Sep 16, 2023 · 2 comments
Closed

Temporary directories/files #145

Jamesernator opened this issue Sep 16, 2023 · 2 comments

Comments

@Jamesernator
Copy link

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

const tempFile = FileSystemFileHandle.createTemporaryFile();
const tempDirectory = FileSystemDirectoryHandle.createTemporaryDirectory();

Alternatives considered

OPFS + beforeunload - This is this only available on the main thread which makes it inconvenient for use in workers

OPFS + 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-handles

Both approaches don't work either if .terminate() is called on a worker as there would be no opportunity for the worker to perform cleanup.

@tomayac
Copy link
Contributor

tomayac commented Sep 16, 2023

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.

@Jamesernator
Copy link
Author

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 .dispose() is called, then files within the storage bucket will still be on disk until disk usage is high. Thus it'd be wasting disk space for something that will never be accessed again.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants