#14596 closed defect (invalid)
InvalidPathException when clicking "Open file" due to a special filename
| Reported by: | bagage | Owned by: | bagage |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | template_report linux | Cc: | dbf, michael.vogt |
Description (last modified by )
Summary: JOSM will issue an error for non-ASCII characters in filenames when system filenames use UTF-8, but the environment settings indicate otherwise. Solution is to fix the environment settings to properly set UTF-8!
What steps will reproduce the problem?
- Open JOSM with "LANG=C josm"
- Click "Open file" icon on top left
What is the expected result?
File chooser is opened and I can select a .*osm file.
What happens instead?
An InvalidPathException is thrown because I've got a file named "Capture d'écran de 2017-03-28 20-05-01.png"
Please provide any additional information below. Attach a screenshot if possible.
Note: running JOSM with "LANG=C.UTF-8 josm" solves the problem. Though, it could be cool if the error could be silently ignored/handled?
Build-Date:2017-03-30 17:49:38
Revision:11772
Is-Local-Build:true
Identification: JOSM/1.5 (11772 SVN en) Linux Debian GNU/Linux 9.0 (stretch)
Memory Usage: 349 MB / 1760 MB (95 MB allocated, but free)
Java version: 1.8.0_121-8u121-b13-4-b13, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java package: openjdk-8-jre:amd64-8u121-b13-4
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13
Plugins:
+ PicLayer (33148)
+ buildings_tools (33004)
+ conflation (0.5.2)
+ jts (32699)
+ rex (26)
+ todo (30000)
+ utilsplugin2 (33182)
Last errors/warnings:
- W: No configuration settings found. Using hardcoded default values for all pools.
- W: Cannot start IPv4 remotecontrol server on port 8111: Address already in use (Bind failed)
- W: Cannot start IPv6 remotecontrol server on port 8111: Address already in use (Bind failed)
- W: Cannot start IPv4 remotecontrol https server on port 8112: Address already in use (Bind failed)
- W: Cannot start IPv6 remotecontrol https server on port 8112: Address already in use (Bind failed)
- E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: ${HOME}/Capture d'��cran de 2017-03-30 22-09-31.png
- E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: ${HOME}/Capture d'��cran de 2017-03-30 22-09-31.png
- E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: ${HOME}/Capture d'��cran de 2017-03-30 22-09-31.png
- E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: ${HOME}/Capture d'��cran de 2017-03-30 22-09-31.png
- E: Handled by bug report queue: java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: ${HOME}/Capture d'��cran de 2017-03-30 22-09-31.png
=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.
Warning issued by: BugReportExceptionHandler#handleException
=== STACK TRACE ===
Thread: Basic L&F File Loading Thread (59)
java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/gautier/Capture d'��cran de 2017-03-30 22-09-31.png
at sun.nio.fs.UnixPath.encode(UnixPath.java:147)
at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
at java.nio.file.Paths.get(Paths.java:84)
at sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:247)
at javax.swing.filechooser.FileSystemView.getFiles(FileSystemView.java:490)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run0(BasicDirectoryModel.java:239)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread.run(BasicDirectoryModel.java:228)
Attachments (0)
Change History (90)
comment:1 by , 8 years ago
| Keywords: | linux added |
|---|
comment:2 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → needinfo |
comment:3 by , 8 years ago
Indeed it does solve my problem (eg. having JOSM in English) and do not have the crash.
I don't know if the UTF-8 issue should be fixed, still. There might(?) be users that run JOSM with system setup with LANG=C?
comment:4 by , 8 years ago
| Resolution: | → invalid |
|---|---|
| Status: | needinfo → closed |
With C you explicitely specify that you have no UTF-8 system, but you pass UTF-8 data to JOSM. Nothing to fix here in my eyes - you simply should not use "C".
It would be better when filesystems would specify the encoding they use, but as far as I know such a functionality does not exist on operation system level.
comment:5 by , 8 years ago
OK fair enough - it'll now use the --language=en option instead to avoid any troubles. Thanks!
comment:15 by , 5 years ago
Hmm, maybe we should catch this error and tell users not to use mismatching encoding specifications?
comment:16 by , 5 years ago
There is no JOSM code involved in the stacktrace, I don't know if we can catch the error.
follow-up: 18 comment:17 by , 5 years ago
We could output a warning at startup when JOSM is launched with LANG=C. Is there any good reason to do so?
comment:18 by , 5 years ago
Replying to simon04:
We could output a warning at startup when JOSM is launched with
LANG=C. Is there any good reason to do so?
I don't think so. Most often it probably is a way to get JOSM using English.
But LANG=C is not wrong. It's only wrong if your filesystem uses UTF-8 encoding and you use non-ASCII filenames. It this case it must be LANG=C.UTF-8 like said above.
Catching the exception and saying something like : Your filesystem character encoding and the encoding JOSM runs ({0}) with don't match. Please fix your setup. If you use LANG=C, don't do it or try LANG=C.UTF-8. There error message is: {1}
Or something similar.
comment:25 by , 5 years ago
| Cc: | added |
|---|
comment:35 by , 5 years ago
Replying to stoecker:
In 17203/josm:
Strange the last duplicates and #20394 show Environment variable LANG: en_US.UTF-8 or similar in the status report.
comment:39 by , 4 years ago
I found 8 tickets since LANG is added to the status report. They all show valid settings (as far as I could see):
Environment variable LANG: es_GT.UTF-8 Environment variable LANG: en_US.UTF-8 Environment variable LANG: en_US.UTF-8 Environment variable LANG: fr_FR.UTF-8 Environment variable LANG: uk_UA.UTF-8 Environment variable LANG: fr_FR.UTF-8 Environment variable LANG: en_US.UTF-8
You need to set a proper
LANGon your OS or use the start option--language.
What is the definition of "proper" LANG?
If --language=en is working, but LANG=en_US.UTF-8 not, could JOSM not try to "translate" the value internally into a working value?
comment:40 by , 4 years ago
https://www.filebot.net/forums/viewtopic.php?p=25560&sid=4c1133b6252f93e8f38eff36ce63543d#p25560 suggests that LC_ALL is relevant, too.
https://support.cloudbees.com/hc/en-us/articles/360004397911-How-to-address-issues-with-unmappable-characters- suggests to set -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8
comment:42 by , 4 years ago
Revision:17699 Is-Local-Build:true Build-Date:2021-04-01 20:26:49 Identification: JOSM/1.5 (17699 SVN de) Mac OS X 11.2.3 OS Build number: macOS 11.2.3 (20D91) Memory Usage: 378 MB / 2048 MB (190 MB allocated, but free) Java version: 16+36, Azul Systems, Inc., OpenJDK 64-Bit Server VM Look and Feel: com.apple.laf.AquaLookAndFeel Screen: Display 1 1440×900 (scaling 2,00×2,00) Display 2 3008×1692 (scaling 2,00×2,00) Maximum Screen Size: 3008×1692 Best cursor sizes: 16×16→16×16, 32×32→32×32 Environment variable LANG: en_IE.UTF-8 System property file.encoding: UTF-8 System property sun.jnu.encoding: UTF-8
comment:43 by , 4 years ago
Related JEP: https://openjdk.java.net/jeps/400
Not yet affected to any Java version, but may very well land in Java 17.
comment:45 by , 4 years ago
Some issues (such as #20726) are related to Flathub. Flathub ticket: https://github.com/flathub/org.openstreetmap.josm/issues/31
Environment variable LANG: en_GB.UTF-8 System property file.encoding: ANSI_X3.4-1968 System property sun.jnu.encoding: ANSI_X3.4-1968
follow-up: 67 comment:66 by , 3 years ago
In Ubuntu 22.04, I noticed this started happening when I started using jOSM from snap version, instead of deb version from repository. I didn't change any option by myself, just the defaults.
comment:67 by , 3 years ago
| Cc: | added |
|---|
Replying to cserpell@…:
In Ubuntu 22.04, I noticed this started happening when I started using jOSM from snap version, instead of deb version from repository. I didn't change any option by myself, just the defaults.
Thank you for this response.
It gives us a place to start debugging why this problem keeps happening.
- The snapcraft (see source:trunk/native/snapcraft.yaml) does not use the start script from source:trunk/native/linux/tested/etc/default/josm. This means that some required start arguments are not added. I don't know if we can use the start script (is JavaFX built into the snap? I don't know, and we kind of require javafx in the start script right now, mostly to avoid bug reports from Microsoft Streetside).
- It looks like we haven't really changed the snapcraft.yml file in 5 years, give or take. Are we even following best practices for snaps any more?
I'll see if I can figure out how to build the snap, and then I'll see if I can make the modifications for it.
follow-up: 75 comment:69 by , 3 years ago
Another issue that is probably related to this one: jOSM does not recognize special accent characters when typing them (in Spanish, á, é, í, ó, ú cannot be typed), but you can copy and paste them from other application. It is very annoying, but it does not break the functionality, though. Interestingly, ñ does work.
comment:73 by , 2 years ago
Is there any way I could help with this? The bug continues. Additionally, regarding my comment (comment 69), should I open another ticket?
comment:74 by , 2 years ago
The problem is in the environment setup which depends on the installer. Both Taylor's #comment:67 about snap and your additional problem are better tracked in separate tickets. Please, use Report Bug from Help menu to insure we get the needed system information.
follow-up: 78 comment:75 by , 2 years ago
Replying to cserpell@…:
Another issue that is probably related to this one: jOSM does not recognize special accent characters when typing them (in Spanish, á, é, í, ó, ú cannot be typed), but you can copy and paste them from other application. It is very annoying, but it does not break the functionality, though. Interestingly, ñ does work.
Replying to skyper:
The problem is in the environment setup which depends on the installer. Both Taylor's comment:67 about snap and your additional problem are better tracked in separate tickets. Please, use [Report Bug] from Help menu to insure we get the needed system information.
I concur with skyper on this. The accents should be handled by the OS (for example, Mac should show a popup if a key is pressed and held, like a, although I both macs I have access to didn't have it enabled).
Beyond that, as far as snap is concerned, it isn't something that is top-of-mind for me, since we already have a repo for Debian/Ubuntu.
comment:78 by , 2 years ago
Replying to taylor.smock:
I concur with skyper on this. The accents should be handled by the OS (for example, Mac should show a popup if a key is pressed and held, like
a, although I both macs I have access to didn't have it enabled).
On MacOS, I use dead keys to type accents. That has always just worked for me, both in JOSM and in other applications. Entering accents in JOSM does provoke some oddities when editing text fields, and with autocompletion. (Dead keys - type Alt+e or Alt+` etc. to specify the accent, followed by the letter which is to receive the accent.)
comment:88 by , 10 months ago
| Description: | modified (diff) |
|---|
From #14068 comments can you please try with
--language=encommand-line argument?