Create the file at path p with the given mode. Then, open it with the given flag.
Get the CentralDirectory object for the given path.
Opens the file at path p with the given flag. The file must exist.
The path to open.
The flag to use when opening the file.
Specially-optimized readfile.
Constructs a ZipFS instance with the given options.
Deprecated. Please use ZipFS.Create() method instead.
Generated using TypeDoc
Zip file-backed filesystem Implemented according to the standard: http://www.pkware.com/documents/casestudies/APPNOTE.TXT
While there are a few zip libraries for JavaScript (e.g. JSZip and zip.js), they are not a good match for BrowserFS. In particular, these libraries perform a lot of unneeded data copying, and eagerly decompress every file in the zip file upon loading to check the CRC32. They also eagerly decode strings. Furthermore, these libraries duplicate functionality already present in BrowserFS (e.g. UTF-8 decoding and binary data manipulation).
This filesystem takes advantage of BrowserFS's Buffer implementation, which efficiently represents the zip file in memory (in both ArrayBuffer-enabled browsers and non-ArrayBuffer browsers), and which can neatly be 'sliced' without copying data. Each struct defined in the standard is represented with a buffer slice pointing to an offset in the zip file, and has getters for each field. As we anticipate that this data will not be read often, we choose not to store each struct field in the JavaScript object; instead, to reduce memory consumption, we retrieve it directly from the binary data each time it is requested.
When the filesystem is instantiated, we determine the directory structure of the zip file as quickly as possible. We lazily decompress and check the CRC32 of files. We do not cache decompressed files; if this is a desired feature, it is best implemented as a generic file system wrapper that can cache data from arbitrary file systems.
For inflation, we use
pako's implementation: https://github.com/nodeca/pakoCurrent limitations: