vfs: apply open(2) effects to ZipProvider handles · nodejs/node@29d3406 · GitHub
Skip to content

Commit 29d3406

Browse files
pipobscureaduh95
authored andcommitted
vfs: apply open(2) effects to ZipProvider handles
A ZipProvider handle keeps its content in memory and adds the entry to the archive when it is closed, and only if something was written. The effects a real `open(2)` has at open time are therefore lost, and so is the metadata the entry already carried: * `open(path, 'w')` followed by `close()` neither truncates an existing entry nor creates a missing one; the same holds for "a" on a missing file. Tools that touch or truncate by open-then-close do nothing. * Rewriting an entry (append, or an in-place write through "r+") re-adds it with the `mode` argument `open()` received (fs's default 0o666), not the mode the entry had, so a 0o755 script silently loses its executable bit. * `fstat` on a handle reports that same `open()` mode and the current time instead of the entry's mode and modification time. * Renaming a file onto an existing directory succeeds and leaves a name that is both a file and a directory; real file systems refuse with EISDIR. This adds a test for each of these against a mounted ZipBuffer, stating the real-fs outcome as the expectation. Proposed solution: mark the handle dirty at open time when the flags imply creation or truncation, so close always commits; carry the existing entry's mode and modification time on the handle, use them for `fstat` and for the re-added entry, and only fall back to the `open()` mode for a newly created entry; and reject `rename` onto an existing directory with EISDIR before touching the archive. Signed-off-by: Philipp Dunkel <pip@pipobscure.com> PR-URL: #65853 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
1 parent ae29cc9 commit 29d3406

1 file changed

Lines changed: 102 additions & 0 deletions

File tree

Lines changed: 102 additions & 0 deletions

0 commit comments

Comments
 (0)