Protected
Optional
Internal
_The last place this file system was mounted
Protected
_Protected
Internal
_The UUID of the file system.
Readonly
attributesProtected
dataProtected
directoriesProtected
eocdProtected
filesReadonly
lazyReadonly
nameThe name for this file system. For example, tmpfs for an in memory one
Readonly
typeA 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: