Save as window does not save file if file extension is missing

[grofaty]

On Ubuntu 20.04 I use Pinta 2.0.2 installed as snap package.

1. Draw something on canvas e.g. line.
2. Click on Save button from toolbar.
3. Click on Picture folder and in Name field type in: "picture" and click on Save button (see attachment).
4. PROBLEM appears: In any kind of application extension is automatically added if not explicitly typed. But even bigger problem. Looking into /home/<user>/Pictures directory and there is no file at all.
5. If in step 3 file extension is added "picture.png" and file is correctly saved in /home/<user>/Pictures directory.

The most strange it is that after step 3 image tab has "picture.png" label, just the same as after step 5.

In my humble opinion this is pretty serious problem. I have lost 5 pictures, because I was convinced pictures were saved, but were not.

[James Carroll (james-carroll)]

This is a horrifying problem, and what's worse, is I doubt this is a problem exclusive to Pinta.

To briefly explain what's happening, the Snap (and Flatpak) use XDG Desktop Portals for the file open and save dialogs. When Pinta is saving the file without the extension, from it's perspective it's absolutely functioning fine. The file is saved in /run/user/$UID/docs/by-app/snap.pinta/picture.jpg

You might be able to access that folder and recover some data, but unfortunately, the /run folder is deleted on every reboot.

What's supposed to happen, is that the system should link the file from /run and make it available where the user actually requested to save it, in the symlink sort of sense (though not actually using symlinks, it basically means the file would appear to exist in both locations and changes to one file are instantly reflected in both locations).

For whatever reason, this isn't happening when the file extension isn't manually appended.

This will certainly be a Linux specific issue, the Windows and Mac builds won't have anything to be concerned with.

I've forwarded this on in the Snapcraft forums, because I can't determine whether this is a problem with the the upstream sources or the specific Ubuntu build, but either way Ubuntu would have to make a patch for this to fix it for everybody involved, so IMO it's ideal to start there and see how it follows on.

In the meantime, it's entirely within my power to disable the use of the portals for the Pinta snap, but as I've said, this issue is almost certainly more widespread than just Pinta alone.

Thank you very much for bringing it up here, hopefully this will be resolved promptly.

[grofaty (grofaty)]

It is another interesting thing. If I try to save to /run/... directory I get error:
You do not have access to modify '.png'. The file or folder may be read-only.

Problem in this bug report is most probably Pinta 2.x problem, I have been using Pinta 1.7 snap for months and I don't even remember ever seeing /run/... folder.

It looks to me that Pinta 2.x uses some system component to save files, but Pinta 1.7 hasn't use it.

Can this be reverted back to Pinta 1.7 behavior? If it is not a big hustle.

[James Carroll (james-carroll)]

I've temporarily reverted it back to the 1.7 behaviour of using an in-process GTK file picker. This is being rolled out to all users now.

I would really like to keep using the portals, they do provide significant benefits in allowing access to the entire file system, rather than just a subset of $HOME (by default; although in the Pinta snap you could also add /mnt and /media by giving it the correct permissions manually, and similarly Flatpak can give more fine grained control still). They also provide nicer integration for KDE users.

But until this critical file loss bug is sorted out this seems to be the only respectable choice.

I can agree with the behaviour you've mentioned of seeing the /run folder appear in UI's being confusing. I wonder if this is because they never anticipated people to make use of the save as functionality more than once per file. Personally, I'm tempted to say the benefits provided by the portals outweigh that one UI flaw, but it might be possible to fix it on the Pinta side. It won't appear in the latest revision though.

If you wish to patch ASAP, run
> sudo snap refresh
Otherwise, the majority of users end up updated quite rapidly too with the automatic update process.

Meanwhile, I'll keep an eye out on the feedback of this bug in the forums, because again, it's quite possibly effecting far more than just Pinta. And the Flatpak should really consider disabling the portals for now too, although I'm unsure if it exhibits the same behaviour, I'd say there's a significant probability it does.

[grofaty (grofaty)]

James, thanks for fixing this problem. I have now refreshed Pinta 2.0.2 snap package and it looks like fixed, no more lost files when saving.

I have now also installed Pinta 2.0.2 from Github by downloading automatically compiled version where there is no file lost.

There is just little difference between github vs. snap package in path display. Snap displays little bit more, but this is tiny difference not effecting any usage. See attachment.

[James Carroll (james-carroll)]

That'll be down to the snap internally having a different value of $HOME than the host. It's not worth fixing because it would genuinely just cause issues elsewhere, the portals would look the same as your host because they are literally your host, and they're a much cleaner solution for it.

As far as the data loss aspect is concerned, it'll likely be fixed by a system package update so I'm unsure if there's any preference on how this ticket is handled. I've found the problem repeatable on other snaps, so it's not a Pinta specific issue.

There might be something we can do about the /run issue being exposed, but I'd suggest continuing discussion in #1958667 just to help keep things understandable. It might be possible to force the UI to just default to the real $HOME, which would be less confusing. It's probably worth looking at how other applications treat this problem, but I do feel the vast majority of people may tend to use ctrl+s as a keyboard shortcut, or just "save" rather than "save as", so the problem is likely mitigated to a certain extent.

[James Carroll (james-carroll)]

There's been a response at https://forum.snapcraft.io/t/xdg-desktop-portal-file-loss/28411/4

Pinta can fix this issue from the application side. The simple explaination is that Pinta should save the file with the exact name it is actually given, rather than trying to add the file extension automatically. By changing the name it saves to, it's treated as a temporary file and is discarded.

I don't like the justification given, but it's at least actionable.

I suppose then this links to #1679570

For the meantime then, it looks like the portals will have to remain off.

[Cameron White (cameronwhite91)]

Yeah, I guess we'll have to just use the file name as-is - this also relates a bit to https://github.com/PintaProject/Pinta/pull/215 which is refactoring some of the file open/save behaviour to use GFile.
We might be able to just pop up a confirmation dialog if the user is trying to save without an extension?

[James Carroll (james-carroll)]

You could add a patch that rejects the filename and makes the user pick again I guess, but I don't personally think it makes much sense. Unless I'm misunderstanding things, once Pinta is patched so that it can open files regardless of their lack of extension, it shouldn't matter what they're actually saved as. Then you could remove the automatic appending of the extension to the filename which would fix this bug.

How this applies to Windows/Mac I'm unsure, there's a chance that the interaction with the native UI dialog's might make this a none issue, e.g on Windows, maybe you're always guaranteed to get an extension even if the user doesn't specify it manually? Unfortunately I've no clue, we'd have to test it I guess.

[Cameron White (cameronwhite91)]

Yeah, the macOS save dialog definitely adds in the extension by default, but I'm not sure offhand what Windows does.

If Pinta can successfully load files that don't have an extension, it's less of an issue. However, wouldn't those files might be subsequently filtered out in the Open File dialog by the "All Images" file filter because they don't have an extension? (making it seem as though the file might have disappeared).
I still think it's a less than ideal user experience - unlike e.g. a text editor, I don't think there's a good use case for saving an extensionless image in the vast majority of use cases

[James Carroll (james-carroll)]

I built Pinta outside the Snap environment, though in this case it seems to work identically to inside the Snap environment (both with and without the portal even). If there is no extension, then it won't appear with the image filter as you expect. What's even weirder however, is that it won't appear even if the filter is disabled (I.E, set to all files).

This doesn't seem to be the case with other apps, they can correctly identify an extensionless file as a valid image, and if their filters are set to images only, they still find results without the extension. (I tested GTK2 based Gimp, LibreOffice, and a few other ones).

I know that the logic for identifying files can be based on not just file extension, but also by inspecting the file header, but I can't figure out where on Ubuntu the magic headers are kept. Presumably though, this is how the native system knows to still open these files properly; and Pinta should be able to benefit from that logic too but doesn't seem to be doing so.

So as is, yes, not having an extension would result in the poor UX you're describing where it wouldn't be visible in the file picker. But it might be that the filepicker is applying too many filters to begin with, because my experience with other applications suggests it totally should be capable of finding extensionless image files.

(All this said, my personal opinion is is that files should have the extensions regardless, because checking the headers is slower than the file extension approach, and it's much easier to do command line manipulations when files are properly tagged)

[grofaty (grofaty)]

I can only write from end-user perspective.

1. Isn't adding file extension by program itself some kind of standard now days? I don't think users should deal with file extensions. Some of the programs I use adds extension regardless what I type in as file name e.g. myfile.txt then becomes myfile.txt.txt. I have trained my family users to NOT type file extensions, because this is properly handled by applications. Some of the users just don't know what file extensions are, and why should they, if there are not power users.

2. Having extension-less files is also pretty bad UX. By looking at the file extension I know exactly what kind of content is in file: picture, text, pdf etc. This would mean I would be forced to manually rename each of Pinta saved image in file manager. Not too much of a problem to me, because I know about this trick, but what about others not technical enough to even understand the point.

3. In my humble opinion, end-user should not suffer any kind of application restrictions applied by packaging system. If there are some security restrictions, they should work transparent in the way they protect users, but do not impose technical stuff to remember.

4. The problem in Pinta is little bit lets say more serious, because also of bug 1435226, that when closing file after it was successfully saved, Pinta still reports that file is not saved. In dialog I trained myself to always just click "Close without Saving" button. This is little annoyance, but with combination of file-extension-snap problem it was devastating to my data lost. Don't know how difficult is this bug to be fixed, it is just annoyance, one of very few left in Pinta.

5. In my humble opinion until some solution is found to not inflict bad UX to non-technical users, it is good solution to not use portal. Data lost or data corruption is my humble opinion on the top of sins application can do.

[Cameron White (cameronwhite91)]

While working on bug 1679570 I also figured out and fixed why the "All Files" filter wasn't including files that didn't have extensions - it was using a pattern of "*.*" which of course only includes files with an extension

Another thought I had is that this situation could be improved a bit if Pinta adds an extension to the default filename when saving, e.g. filling it in as "Unsaved image 1.png" (or whatever the last used extension was) rather than just "Unsaved image 1" which immediately puts the user into this scenario

[James Carroll (james-carroll)]

I do agree with your points Grofaty, there has been some changes in the master branch just now that help with this bug (though there's still work to be done of course, this is just part of the UX aspect). While I personally think all files should have extensions, Linux as a platform has a lot of functionality that avoids the need for it, so to some users, it's a reasonable expectation that an image is an image regardless of what it's called.

Pinta can now identify your image files regardless of their extension on Linux in most cases. If you save a file as just "example", and it's a valid jpeg; Pinta will now present it in the file picker properly whilst avoiding presenting any files that aren't images. The logic here should be shared across the majority of the OS, which means that similarly, the file manager should already show a preview thumbnail and right clicking will highlight Pinta as a possible editor for opening the file, or the general image viewer application, etc, even if there's no extension.

There's still considerations such as changing the default recommended name to include an extension by default, possibly throwing a warning it one isn't included, and of course, fixing the underlying data loss bug; but the UX concerns around a file appearing to be missing just because it doesn't have an extension should be a lot better.

[Cameron White (cameronwhite91)]

I've pushed some more changes to https://github.com/PintaProject/Pinta/tree/feature/native-save-dialogs
It now adds an extension to the initial placeholder filename when saving a new file, and also just uses the native save dialog as-is (using the selected filename without any modifications, which should fix the portal issue)

The downside is that the GTK file dialog doesn't auto-update the extension if you change the filter (https://gitlab.gnome.org/GNOME/gtk/-/issues/402), and also doesn't provide a signal to let us do that ourselves (https://gitlab.gnome.org/GNOME/gtk/-/issues/4626). But this would be the standard behaviour that all other GTK apps on the system would have so it's not an odd behaviour specific to Pinta...

[James Carroll (james-carroll)]

I gave those changes a go, with both xdg-desktop-portal-gtk and xdg-desktop-portal-kde, the behaviour in both works as expected; the filename is automatically appended and saves without an extension work just fine.

In the case of the KDE backend, the file dialog will actually assist with swapping and appending the file extension automatically, so KDE users should rarely save extensionless files (there's an option on the UI to manage it). From Pinta's perspective, the user just always happens to save a file with an extension (which makes me wonder why GTK doesn't do the same thing, given how severe the consequences can be).

Of course, there's still the behaviour of revealing the /run folder in bug 1958667, but as far as data loss is concerned, this looks a lot better. ( I won't say it's perfect because I'd rather give more than 5 minutes of casual testing given this has bitten once before ! )

[Cameron White (cameronwhite91)]

Great, thanks for testing!
For the /run folder, the only other thing to try would be seeing if `fcd.CurrentFolder` or `fcd.CurrentFolderFile` work for the portal dialog, and if they return the "original" folder rather than the folder of the portal file that Pinta gets (currently, `fcd.File.Parent` is used to get the last dialog directory)

[Cameron White (cameronwhite91)]

I've merged those changes in https://github.com/PintaProject/Pinta/commit/456790b6bc4e5ae860161fcda92392b8f7c4dd38