EACCES Error relating to 7za when creating backup archive about joplin-plugin-backup HOT 15 CLOSED

I've found the problem; the snap turns off Asar bundling because I copied the idea from the Flatpak. I believe the idea in the flatpak is that by removing the bundling, the Flatpak update mechanism can more efficiently target specific files that have changed between releases. Snap updates don't work the same way and update (usually) via the delta's between two squashfs files, so for me it's trivial to just turn the asar bundling back on to fix the built-in Simple Backup plugin.

Once that's done, the snap works exactly as expected.

Strictly speaking, this is somewhat a Simple Backup issue because the exact error was it was looking at the wrong path when Asar bundling is turned off, causing it to not identify the 7za file even though there is one, so other potential future bundled plugins could work fine with Asar bundling turned off.

On the other hand, it's a packaging issue, since all the official releases have Asar bundling turned on.

Long story short, the snap looks good but the flatpak probably needs investigating separately for their Asar settings.

from joplin-plugin-backup.

This should be fixed in version 2.14.11!

from joplin-plugin-backup.

I've tested it in 2.14.11 and it works!

Thank you.

from joplin-plugin-backup.

• Is this with the Buildin Backup Plugin oder with a seperated installed ?
• I think it's about a snap installation?
• Yes, the backup cannot continue because it has no access to 7za and is terminated

from joplin-plugin-backup.

Hi I'm using the AppImage version of Joplin desktop from the Joplin web site.

I haven't installed any plugins myself, I'm using the included 'Backup' plugin that came with the AppImage.

from joplin-plugin-backup.

@personalizedrefrigerator Can you possibly help? Since you have customized something for the default installation on 7zip.

from joplin-plugin-backup.

Thank you for reporting this! I can reproduce this on Ubuntu 23.10.

Because of code signing issues on MacOS, we bundle 7zip with Joplin (rather than with the .jpl file for Simple Backup).

Semi-related (but different) issues on other projects.

• AppImage/AppImageKit#1021
• marktext/marktext#1164 (comment)

My guess would have been that /tmp is mounted as noexec. However, on my system, I'm able to create a subdirectory of /tmp, put an executable in it, and execute it (so this probably isn't a noexec issue).

One possible solution could be to copy 7zip/7za to a different location before executing it on Linux. For example, to a subdirectory of ~/.config/joplin-desktop/cache.

from joplin-plugin-backup.

Also I wonder how that will work once the app is bundled with Snap?

Perhaps as a fallback we could simply not compress the backup if 7-zip fails?

from joplin-plugin-backup.

Maybe check in advance if 7 zip is executable and if not deactivate the compression and password options (do not show).

from joplin-plugin-backup.

I liked the idea of putting the 7za executable in ~/.config/joplin-desktop/cache or it could be temporarily put into the 'Temporary export path'.

from joplin-plugin-backup.

Pull request: laurent22/joplin#9780

from joplin-plugin-backup.

I'm using the included 'Backup' plugin that came with the AppImage.

This should be Simple Backup v1.3.5 -- Joplin's default plugin build script points to commit bd49c66 which is version 1.3.5. (We didn't update to 1.3.6 because the only listed change was related to plugin metadata (icons & screenshots) ).

As such, if the about screen shows version 1.3.6, there's probably a bug somewhere. (For me, it shows version 1.3.5, but I'm testing with a self-built AppImage).

from joplin-plugin-backup.

Also I wonder how that will work once the app is bundled with Snap?

I don't expect the 7za binary to be too problematic. I can either wrap around it, bundle the Ubuntu version, or patch the plugin itself since it's now essentially part of the core app; assuming it's even a problem, it might happen to work just fine.

I've tried to test it now to confirm but unfortunately the plugin when loaded from from the Joplin executable (I.E 2.14.x) doesn't initialise properly. The plugin is shown as installed and as built-in, but the config for the plugin in the options menu doesn't load at all.

As far as 2.13.x goes installing it manually, the functionality works just fine, so assuming I can figure out why the UI won't load, I'd expect the 2.14.x version to work fine too.

from joplin-plugin-backup.

I've tried to test it now to confirm but unfortunately the plugin when loaded from from the Joplin executable (I.E 2.14.x) doesn't initialise properly. The plugin is shown as installed and as built-in, but the config for the plugin in the options menu doesn't load at all.

This might be fixed by laurent22/joplin@b51e16c, which removes duplicated logic for finding the location of the build/ directory at runtime. The original code for doing this, present in ElectronAppWrapper.ts, might work even if Asar bundling is turned off.

from joplin-plugin-backup.

It's certainly helpful for the flatpak. When I've evaluated it in the context of the snap, the only benefit is making it easier for people to see the shipped source code and perhaps (untested) some improvement in file access since every file is already archived? The main downside is very subtle breaking of API versus the official builds.

https://www.electronjs.org/docs/latest/tutorial/asar-archives#limitations-of-the-node-api

On balance, I don't think the behaviour breakages, rare as they may be, are worth the few people who might peek at the source code on the file system rather than via GitHub, especially given the build output is already processed by Typescript and is essentially not the real source anymore. Again, the Flatpak might disagree as their bandwidth usage on downloads will likely go significantly up, but ultimately that's Flathubs problem and I personally don't think it's worth shipping unnecessary behaviour changes on top of those that already make us weird by being sandboxed too.

from joplin-plugin-backup.