Saving without having to append bbmodel

Luke100000 commented 5 months ago

What are you trying to do, and what do you expect to happen?

Create a generic model, add a cube, save project.

What happens instead?

It suggests the file name without extension, confirms success via popup, but doesn't actually output the desired file. It does however generate .xdp-test.bbmodel-ctkIdH, so I assume renaming the temporary output file to the final name failed. I am using the Flatpak build, and iirc, it never happened on the other builds/web.

Model format in which the issue occurs

Generic

Blockbench variant

Program

Blockbench version

4.9.1

Operating System

Manjaro Arch Linux

Installed Blockbench plugins

none

Luke100000 commented 5 months ago

Slightly related to the overall Issue, you can not open bbmodel files via drag and drop as it does not find the file. Most likely an permission error., as --filesystem=host fixes that. It will not fix the main issue. Same with double click, it will complain that a temporary path does not exist.

JannisX11 commented 5 months ago

This sounds like an issue with node or with your system most likely, not an issue with Blockbench itself. Where did you try to save the file?

Luke100000 commented 5 months ago

For example in the home dir. 777 permission also won't work. It affects saving but also exporting, e.g. for exporting as obj I get two files .xdp-sdafd.mtl-4TdakY, .xdp-sdafd.obj-ssiQL7. Adding the extension manually works fine again. No errors in console or terminal.

daenney commented 5 months ago

Hiya! I'm the person maintaining the Flatpak bundle, so let me chime in here. In flathub/net.blockbench.Blockbench#50 this same issue came to light and is generally a permission issue.

By nature of the sandboxing, you can only save to certain locations. In the case of the Flatpak, these are specified here: https://github.com/flathub/net.blockbench.Blockbench/blob/1f8ce174a9c06997d5e2636bce6e295a9e3ce0df/net.blockbench.Blockbench.yaml#L16-L22:

  - --filesystem=xdg-desktop
  - --filesystem=xdg-documents
  - --filesystem=xdg-download
  - --filesystem=xdg-music
  - --filesystem=xdg-pictures
  - --filesystem=xdg-public-share
  - --filesystem=xdg-videos

These are all read-write paths. xdg-destkop is $HOME/Desktop, xdg-pictures is $HOME/Pictures etc. If you've removed access to any of those using the flatpak CLI or a tool like Flatseal, or pick a location to which the app doesn't have write access then you'll probably get the issue described here.

What I'm a little surprised about is that no user visible error happens. The user asked to save a file to a location and clearly that was only partially successful.

Electron should nowadays have functioning support for the XDG Document portal so we could omit the finish args and instead rely on giving access that way "in the moment". But that would only work if it ends up needing to write a single file as you can't tell it yet it can write ancillary files too into the same location. That might also create a problem when opening a project, if it needs to read/load additional assets. So for now using the Documents portal might not be an option.

AnderHominem commented 1 hour ago

I'm also using Linus Mint 21.3 and I have a similar problem, but it works in an extremely weird way. So I tried using the flakpack version, it worked fine overall, program only crashed if I tried to relaunch it, ie 2 windows at once. Also in the flatpack version I faced this problem https://github.com/JannisX11/blockbench/issues/2186 so for reliability I switched to the deb package version.

And on this version, program works super weird, on first startup it always crashes no matter what, on repeated startup it works fine, but if I run the program again when it's already running it crashes. But the strangest part is that if my USB speakers are turned off, the program always crashes on startup (this is only on the deb pack, flatpack works without changes), if I turn on the speakers, the program starts normally again, then turn it off, it crashes again on startup. Tried many times and In fact, it's so consistent that there definitely must be some connection

JannisX11 / blockbench