Save always displays as succesful even when not (e.g. due to permissions), leading to data loss

[anonymous]

What steps will reproduce the problem?

1. use save method upon exiting application with unsaved changes, Try to save to a location without write permission
2. Watch on-screen display message in JOSM state the file has been successfully saved
3. Check existence of file

What is the expected result?

Either error message and offer user to try saving again without exiting JOSM yet.

What happens instead?

JOSM just exits and files are lost, trying to recuperate them from autosave/deleted layers folder hopefully works then.

Please provide any additional information below. Attach a screenshot if possible.

Installed as a Flatpak from Flathub through KDE Discover.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2023-01-29 21:53:34 +0100 (Sun, 29 Jan 2023)
Revision:18646
Build-Date:2023-01-30 02:30:56
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18646) Linux Freedesktop.org SDK 22.08 (Flatpak runtime)
Memory Usage: 174 MB / 3962 MB (75 MB allocated, but free)
Java version: 17.0.4.1+12, Flathub, OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
Screen: :0.0 1672×940 (scaling 1.00×1.00)
Maximum Screen Size: 1672×940
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_GB.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info:
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: KDE
VM arguments: [--module-path=/app/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]

Tagging presets:


Validator rules:

[anonymous]

To add, another instance of this issue #21366 was closed as a duplicate of #20305 . Yet as mentioned in https://josm.openstreetmap.de/ticket/21366#comment:3 by GerdP the assumption of JOSM that a file was succesfully saved is the bug here, not the hidden folders as a consequence of flatpak permission system.

JOSM should simply not assume a file has been saved when it is not. To demonstrate, I tried saving a file to the system root (/), which succeeded! And when trying to save a different file there under the same name, it offered to replace an existing file. Apparently it remembered saving it there yet the file is nowhere to be found. Nothing like that should ever happen.

Please think about addressing or at least reopening the bug, and make sure your application remains reliable.

[stoecker]

Replying to anonym:

JOSM should simply not assume a file has been saved when it is not. To demonstrate, I tried saving a file to the system root (/), which succeeded! And when trying to save a different file there under the same name, it offered to replace an existing file. Apparently it remembered saving it there yet the file is nowhere to be found. Nothing like that should ever happen.

When I try to save a file to "/" it correctly rejects this with an error. Your description that "Apparently it remembered saving it there" sounds much more like you are using some sort of overlay or virtual file system which presets a different directory structure to JOSM than what the other programs you use show you. That's easy to verify. Simply save a file in JOSM and later try to open it. You should check your system and search what structure you have.

If JOSM can save and load files, then they are somewhere. It's not JOSMs task to understand where that somewhere is.

[taylor.smock]

Java version: 17.0.4.1+12, Flathub, OpenJDK 64-Bit Server VM

I believe this is a bug with the flatpak. See ​https://github.com/flathub/org.openstreetmap.josm/issues/14 -- at this time, the flatpak can only read/write to the Download folder by default, and the various configuration directories. Any other location in flatpak should be assumed to be in the sandbox, and I have no clue where the sandbox actually saves files in /.

See ​https://bugs.openjdk.org/browse/JDK-8284516 for the upstream bug.

We should probably ask the flathub packagers to allow full filesystem access. Which isn't ideal from a sandbox perspective, but without JDK support, we are kind of limited in what we can do.

[stoecker]

Flatpak, another "broken by design" idea...

[anonymous]

As an end user, I am merely downloading JOSM from Flathub, which lists "JOSM Developers" as the author. I have no concept of overlay filesystems.

Using mechanisms such as Flatpak and Snap are increasingly becoming the default for desktop Linux. Users just open their software store, search for JOSM and hit the first result. For JOSM, only Ubuntu has a native package.

While I respect your position as developers due to bugs in Java (a legacy platform) and all of these technicalities, I don't see why pointing to the end user, or other software, would truly warrant closing the ticket.

JOSM developers could take ownership of the Flatpak listing (which is mostly a one-time effort). Or, for the time being, display a simple warning message if it was built as a flatpak, indicating the problem.

Alternatively, to have at least some form of feedback, just list the full file path in the tooltip message when saving. Or include it in the stdout.

The problem resides in the fact that the user experience does not match with the reality: the file does not save in the location. As an end user that is a fatal issue and enough to not use the application

[anonymous]

Replying to taylor.smock:

Java version: 17.0.4.1+12, Flathub, OpenJDK 64-Bit Server VM

I believe this is a bug with the flatpak. See ​https://github.com/flathub/org.openstreetmap.josm/issues/14 -- at this time, the flatpak can only read/write to the Download folder by default, and the various configuration directories. Any other location in flatpak should be assumed to be in the sandbox, and I have no clue where the sandbox actually saves files in /.

See ​https://bugs.openjdk.org/browse/JDK-8284516 for the upstream bug.

We should probably ask the flathub packagers to allow full filesystem access. Which isn't ideal from a sandbox perspective, but without JDK support, we are kind of limited in what we can do.

Hello, thank you for your efforts in looking into the issue. I understand now it's not directly JOSM's fault.

Please refer to my previous comment for a quick fix to mitigate the issue in the meantime. JOSM could at least display the file path, or detect Flatpak from the build string and alert the user/instruct him to change permissions. I'm sorry as I don't have enough Java skill to write up a patch myself.

Best of luck

[taylor.smock]

@stoecker: Would you be opposed to adding some functionality to have "known-good" read/write paths?

I took a look at the /.flatpak-info file (which is apparently always present in a flatpak), and there is a filesystems entry.

Example:

[...snip...]
[Context]
[...snip...]
filesystems=xdg-download;

I fiddled with permissions a bit with flatseal, and it looks like the special values we have to worry about are as follows:

• xdg-* (xdg-download, xdg-pictures, etc., we can get the path by running xdg-user-dir ${upper case xdg directory, e.g. DOWNLOADS})
• host (allow all)
• host-etc (allow /etc)
• host-os (not well documented, but we can probably ignore it)
• home (the user home directory)
• Fully defined paths (/mnt/somewhere for example)
• Home paths (~/somewhere)

[stoecker]

I don't understand the question.

P.S. I actually don't like Flatpak and Snap much. These are essentially methods to get rid of the OpenSource concept.

[taylor.smock]

Replying to stoecker:

I don't understand the question.

I was thinking of adding some functionality to PlatformHooks to get permissible locations for writing data. In retrospect, I should probably figure out why flatpak allows writing to ephemeral locations.

P.S. I actually don't like Flatpak and Snap much. These are essentially methods to get rid of the OpenSource concept.

I like flatpak (but not snap) since flatpak allows arbitrary organizations to serve their own flatpak repo. And I use an immutable distribution (Fedora Silverblue) on my home computer, so I kind of need something like flatpak or snap to install additional applications.