PintaProject
Unhandled exception when saving with certain file names
Description I'm getting an Unhandled exception with certain file names like "Schärfen1.jpg".
If I instead name the file "Schaerfen1.jpg", the file saves without issues.
Characters like @, + seem to work
Characters like ö, ä, ü and § seem to cause the unhandled exception
Characters like < and | seem to cause a different error message or cause Pinta to choose a random file name.
To Reproduce
- I open a bunch of files from smb://[email protected]/Drive k9/Documents and Files/Documents/eBay/pictures/2025/July/ in Pinta
- I make my edits
- I press Control + Shift + S to Save as
- I stay in the same directory and name my file "Schärfen1.jpg"
- I get the following error message:
"Unhandled exception
Invalid byte sequence in conversion input
GLib.GException: Invalid byte sequence in conversion input at GLib.Internal.NullablePlatformStringHandle.ConvertToString() at Gio.FileHelper.GetRelativePath(File descendant) at Pinta.Actions.SaveDocumentImplmentationAction.SaveFileAs(Document document) at Pinta.Actions.SaveDocumentImplmentationAction.Activated(Object sender, DocumentCancelEventArgs e) at Pinta.Core.FileActions.RaiseSaveDocument(Document document, Boolean saveAs) at Pinta.Core.Document.Save(Boolean saveAs) at Pinta.Actions.SaveDocumentAsAction.Activated(Object sender, EventArgs e) at Pinta.Core.Command.<.ctor>b__29_0(SimpleAction o, ActivateSignalArgs args) at GObject.Closure.InternalCallback(IntPtr closure, IntPtr returnValuePtr, UInt32 nParamValues, IntPtr paramValuesData, IntPtr invocationHint, IntPtr userData)"
Additional Info
Version Operating System: openSUSE Tumbleweed-Slowroll 20250701 KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.4-1.0.12.sr20250601-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 8945HS w/ Radeon 780M Graphics Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS Vivobook S 15 System Version: 1.0
Pinta 3.0.2 Flatpak
Yes, it also happens when I copy a file to ~/Downloads before opening it and I use "Save as" in that directory.
It works for me with version 3.0.2 via the flatpak and from source under fedora 42. So there is probably something unexpected happening on your system.
Can you give the output of the following command in the shell?
echo $LANG
`k9@linux:~> echo $LANG en_US.UTF-8
k9@linux:~> locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=de_DE.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= `
I have set my system to English but I use German for most data.
Hm, I started pinta via LANG=en_US.UTF-8 dotnet run and it works, too.
Can it be, that the file you are using was created by windows and it's name is not encoded in UTF-8? If you then load the file from a linux environment this could probably crash.
What happens if you just create a new empty image and use the same filename?
@cameronwhite: Perhaps GirCore should raise a dedicated exception for filename encoding errors so that it is possible to react to this specific exception and rescue the UI instead of crashing it?
Perhaps there could even be a specialized Type for "FileSystemStrings" so that there is not all the conversion happening to C# strings. So a caller could call "ToString()" to create a C# string from it if needed. This could be done for UTF8-Strings and Filename strings.
It also happens when I try to save an image I just created in Pinta.
I've also noticed that the log shows the following error:
k9@linux:~> flatpak run com.github.PintaProject.Pinta
(process:2): Gtk-WARNING **: 21:25:54.325: Locale not supported by C library. Using the fallback 'C' locale.
(pinta:2): Gtk-WARNING **: 21:25:55.561: GtkBox 0x55fa8274c140 (box) reported min width 505 and natural width 483 in measure() with for_size=704; natural size must be >= min size
(pinta:2): Gtk-WARNING **: 21:25:55.572: GtkBox 0x55fa8274c140 (box) reported min width 505 and natural width 483 in measure() with for_size=832; natural size must be >= min size Pinta: Unhandled exception GLib.GException: Invalid byte sequence in conversion input at GLib.Internal.NullablePlatformStringHandle.ConvertToString() at Gio.FileHelper.GetRelativePath(File descendant) at Pinta.Actions.SaveDocumentImplmentationAction.SaveFileAs(Document document) at Pinta.Actions.SaveDocumentImplmentationAction.Activated(Object sender, DocumentCancelEventArgs e) at Pinta.Core.FileActions.RaiseSaveDocument(Document document, Boolean saveAs) at Pinta.Core.Document.Save(Boolean saveAs) at Pinta.Actions.SaveDocumentAsAction.Activated(Object sender, EventArgs e) at Pinta.Core.Command.<.ctor>b__29_0(SimpleAction o, ActivateSignalArgs args) at GObject.Closure.InternalCallback(IntPtr closure, IntPtr returnValuePtr, UInt32 nParamValues, IntPtr paramValuesData, IntPtr invocationHint, IntPtr userData)
I just played around with the flatpak config command and after running the following commands I can save without issues:
flatpak config --set extra-languages "en;en_US.UTF-8;de_DE.UTF-8"
flatpak update
languages and extra-languages was unset before.
I don't understand what was wrong in the first place.
Perhaps GirCore should raise a dedicated exception for filename encoding errors so that it is possible to react to this specific exception and rescue the UI instead of crashing it?
Yeah that sounds reasonable to do 👍
Perhaps there could even be a specialized Type for "FileSystemStrings" so that there is not all the conversion happening to C# strings. So a caller could call "ToString()" to create a C# string from it if needed. This could be done for UTF8-Strings and Filename strings.
In Pinta we're using GFile for file access - it stores the raw file name internally (https://docs.gtk.org/glib/character-set.html) and then we use https://docs.gtk.org/gio/method.File.query_info.html to get a name that can be displayed safely in the UI (e.g. maybe replacing any invalid characters). The latter is always a safe conversion from utf8 to a C# string
In the specific case where we're hitting this error, we need to find out the extension of the file chosen by the user, but actually can't use File.QueryInfo() because it fails if the file doesn't exist on disk yet.
(I'm not sure why we called GetRelativePath() to do this rather than just file.GetBasename(), but maybe that wasn't generated at the time.)
If we had an extension method that called g_filename_display_basename(g_file_get_path(file)) to get a best-effort conversion, I think that would probably be sufficient for this use case
But more generally, having a PlatformString that requires explicit conversion to a C# string might be a good way to solve this
From reading through the glib docs, I suspect that G_FILENAME_ENCODING was probably affected by the locale settings. If it's set to @locale, it calls g_get_charset() to choose the character set based on the current locale
https://docs.gtk.org/glib/func.get_charset.html https://docs.gtk.org/glib/func.get_filename_charsets.html