Protected
Optional
Internal
_mountThe last place this file system was mounted
Protected
_timeReadonly
attributesProtected
dataProtected
directoriesReadonly
eocdProtected
filesReadonly
idA unique ID for this kind of file system. Currently unused internally, but could be used for partition tables or something
Readonly
nameThe name for this file system. For example, tmpfs for an in memory one
Create the file at path
with the given options. Then, open it with flag
.
Create the file at path
with the given options. Then, open it with flag
.
Abstract
openAbstract
readReads into a buffer
The buffer to read into. You must set the byteOffset
and byteLength
appropriately!
The offset into the file to start reading from
The position in the file to stop reading
Abstract
readdirReads into a buffer
The buffer to read into. You must set the byteOffset
and byteLength
appropriately!
The offset into the file to start reading from
The position in the file to stop reading
Abstract
statOptional
data: Uint8ArrayOptional
stats: Readonly<Partial<StatsLike>>Optional
data: Uint8ArrayOptional
stats: Readonly<Partial<StatsLike>>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
Protected
Static
computeEOCDLocates the end of central directory record at the end of the file. Throws an exception if it cannot be found.
Unfortunately, the comment is variable size and up to 64K in size. We assume that the magic signature does not appear in the comment, and in the bytes between the comment and the signature. Other ZIP implementations make this same assumption, since the alternative is to read thread every entry in the file.
Offsets in this function are negative (i.e. from the end of the file).
There is no byte alignment on the comment
Zip file-backed filesystem 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. 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.
Current limitations: