Conversation
On Arch, "Install and Relaunch" asked for a root password and then ran `dpkg -i`, a Debian command that does not exist there, so the in-app updater never worked and every update had to be fetched and installed from a terminal by hand. Reported on Discord by Kelv, on CachyOS. The cause is in the build, not the app. electron-builder stamps a `package-type` file into the install, and electron-updater reads it to decide which release asset to download and which installer to run. All five Linux targets are cut from ONE staging directory, they build concurrently (isAsyncSupported defaults to true), and only the deb and rpm targets write that file, so a package ships whichever value a neighbour happened to leave behind. Confirmed against the published 2.39.0 downloads: the .pacman carried `deb`, while the .deb and .rpm were correct. One file and several racing writers cannot be fixed at build time, so this stops trusting the stamp's contents. The format now comes from the running system: /etc/os-release ID, then ID_LIKE, which is what carries the derivatives (CachyOS declares ID_LIKE=arch) we would otherwise have to enumerate one by one. The stamp is still consulted, but only for whether it exists, because that is the one true thing it says: only a ZenNotes system package carries it. An AppImage and an AUR or tarball install have none and are deliberately left exactly as they were, updating in userspace and through their own package manager respectively. An unrecognized distro changes nothing. A build-time fix was written first and dropped on purpose: a hook can stamp each package as it is built, but with the targets racing over one file it is only usually right, and "usually" is what shipped this bug. As a backstop, an update whose format contradicts the system no longer reaches pkexec. Instead of a root prompt for a command the machine does not have, ZenNotes names the package it needs and links the download. Arch users on 2.39.0 or earlier carry the wrong stamp in the copy they already have, so this one still needs a manual install; from here it installs itself. Not exercisable on the release host (no Linux machine): the decision and the guard are unit-tested, and the packaged macOS build was launch checked over CDP, but the pacman install has not been run end to end. Claude-Session: https://claude.ai/code/session_01AYTRixg5TJmxn2j6FCqfUD
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Attaching or dropping a file wrote a different link depending on which surface you did it from. Paste, and an existing asset dragged in from the sidebar, embedded a vault-relative wikilink; a drop wrote a markdown link with a path relative to the note, ``, and the self-hosted server produced that same note-relative form for the web client. The mobile apps had a third answer again. Same file, same folder, three different links. The note-relative form was also wrong, not merely different: nothing rewrites relative asset paths when a note moves, so `../assets/pic.png` broke the moment the note changed depth. So there is now one rule, everywhere: the file lands in `assets/` and is linked by VAULT-relative path, an image as `![[assets/pic.png]]` and anything else as `[name](<assets/report.pdf>)`. That is what paste and the sidebar drag already wrote, so this moves the odd routes onto the form the app already used most. Existing notes are unaffected: resolveAssetVaultRelativePath tries note-relative, then vault-root, then a unique basename, so both the old and the new form keep resolving on both rendering surfaces. `ImportAsset` no longer reads notePath, since where the note lives can no longer change what is written; it stays in the signature because the handler and clients still send it. The matching mobile fixes ship in the zennotesandroid and zennotesios repos. Claude-Session: https://claude.ai/code/session_01AYTRixg5TJmxn2j6FCqfUD
adibhanna
changed the title
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.
Opens the 2.40.0 cycle. Two fixes so far.
1. The Linux updater installs the package you actually run
Report (Kelv, Discord, CachyOS): "Install and Relaunch" asked for a root password and then ran
dpkg -i, a Debian command that does not exist on Arch, so the updater never worked and every update had to be installed from a terminal by hand.Cause, which is in the build. electron-builder stamps a
package-typefile into the install, and electron-updater reads it to decide which release asset to download and which installer to run. All five Linux targets are cut from one staging directory, they build concurrently (platformPackager.js:105-126;isAsyncSupporteddefaults true incore.js:49), and only the deb and rpm targets write that file (FpmTarget.js:117,supportsAutoUpdateat:234). A package ships whichever value a neighbour left behind.Verified against the published 2.39.0 downloads:
.pacmandeb.debdeb.rpmrpm.tar.gzFix. One file with several racing writers cannot be made reliable at build time, so the app stops trusting the stamp's contents and takes the format from
/etc/os-release(ID, thenID_LIKE, which carries derivatives like CachyOS without enumerating them). The stamp is consulted for presence only, so an AppImage and an AUR or tarball install keep behaving exactly as they do today. A build-time hook was written first and dropped on purpose: with the targets racing over one file it is only usually right, and "usually" is what shipped this bug. As a backstop, an update whose format contradicts the system never reachespkexec.Arch users on 2.39.0 or earlier carry the wrong stamp already, so 2.40.0 needs one last manual
sudo pacman -U; after that it installs itself.2. Every device links an attached file the same way
Attaching or dropping a file wrote a different link depending on where you did it. Paste, and an existing asset dragged from the sidebar, embedded a vault-relative wikilink; a drop wrote a note-relative markdown link
; the self-hosted server produced that same note-relative form for the web client; and the mobile apps had a third answer. Same file, same folder, three different links.The note-relative form was also wrong, not merely different: nothing rewrites relative asset paths when a note moves, so
../assets/pic.pngbroke the moment the note changed depth.One rule now, everywhere: the file lands in
assets/and is linked by vault-relative path, an image as![[assets/pic.png]]and anything else as[name](<assets/report.pdf>).../linkExisting notes are unaffected:
resolveAssetVaultRelativePathtries note-relative, then vault-root, then a unique basename, so both the old and the new form keep resolving on both rendering surfaces.The mobile half ships separately, in ZenNotes/zennotesandroid#41 and ZenNotes/zennotesios#15, which also fix corrupted attachment uploads to a self-hosted server.
Verification
npm run packcompleted and produced a locally signed macOS app/opt/ZenNotes/resourcespackage detection, leaked stamps in tar/AUR layouts, and explicit updater selectionRelease preparation
All workspace manifests are now 2.40.0. Electron Builder is upgraded to 26.15.7 for pacman updater metadata, with the upstream dependency-cycle guard carried as a patch; packaging succeeds with that patch applied. Local packaging intentionally skipped notarization because Apple credentials are held by the GitHub release workflow.
The pacman installer itself cannot be exercised end to end on this macOS host; the release matrix will build and validate Linux x64 and arm64 artifacts in CI.