Protected Optional Internal_The last place this file system was mounted
Protected_Protected Internal_The UUID of the file system.
ReadonlyattributesProtecteddataProtecteddirectoriesProtectedeocdProtectedfilesReadonlylazyReadonlynameThe name for this file system. For example, tmpfs for an in memory one
ReadonlytypeA unique ID for this kind of file system. Currently unused internally, but could be used for partition tables or something
Create the file at path with the given options.
Create the file at path with the given options.
Test whether or not path exists.
Test whether or not path exists.
Reads into a buffer
The buffer to read into. You must set the byteOffset and byteLength appropriately!
The position in the file to stop reading
Reads into a buffer
The buffer to read into. You must set the byteOffset and byteLength appropriately!
The position in the file to stop reading
Read a file using a stream.
Write a file using stream.
Modify metadata.
Modify metadata.
Writes a buffer to a file
The buffer to write. You must set the byteOffset and byteLength appropriately!
The offset in the file to start writing
Writes a buffer to a file
The buffer to write. You must set the byteOffset and byteLength appropriately!
The offset in the file to start writing
A file system backend by a zip file. Implemented according to the standard: http://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 ZenFS. 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 ZenFS (e.g. UTF-8 decoding and binary data manipulation).
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.
Current limitations: