fix: use relative path for attachment entries in export zip - #2339
Open
TowyTowy wants to merge 1 commit into
Open
fix: use relative path for attachment entries in export zip#2339TowyTowy wants to merge 1 commit into
TowyTowy wants to merge 1 commit into
Conversation
Attachment files were written to the export archive with an absolute "/files/..." entry path. A leading slash produces an absolute zip entry, which violates the ZIP spec (APPNOTE 4.4.17) and is rejected by tools such as Windows Explorer, leaving the archive unextractable. It also mismatches the relative "files/..." URLs written into the exported pages by updateAttachmentUrlsToLocalPaths, so attachment links break after extraction. Use a relative "files/..." path so the archive is spec-compliant and the in-document links resolve. Fixes docmost#1307 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #1307. When exporting a space (or a page tree) with attachments, the generated ZIP is invalid: Windows Explorer (and other spec-strict tools) cannot extract it. Attachment entries are written with a leading slash — an absolute path — which violates the ZIP spec (APPNOTE.TXT §4.4.17).
There is a second, silent consequence: exported pages reference attachments with the relative
files/...URL (viaupdateAttachmentUrlsToLocalPaths), but the archive stores them at the absolute/files/...entry — so even when extracted, the links don't resolve for root-level pages.Fix
Write attachment entries with a relative
files/...path. This makes the archive spec-compliant and aligns the entry path with the relative URLs already written into the documents, so links resolve after extraction. Nested pages are unaffected (JSZip already normalizes the slash inside subfolders); the bug is specific to root-level pages, which is the space-export case in the report.Testing
Added
export.service.spec.tscoveringzipAttachments: it asserts entries use a relative path (no leading slash) and are placed relative to the page folder. Verified fail-before/pass-after by reverting the one-line change (the root-page test fails with an absolute/files/...entry before). Confirmed the leading-slash behavior directly againstjszip@3.10.1;tsc --noEmitclean.Notes / disclosure
@sindresorhus/slugify(unrelated to zipping) so the export service can be imported under the current jest config without any config change.