#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 |
Description
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 (52)
comment:1 Changed 5 years ago by
| Keywords: | linux added |
|---|
comment:2 Changed 5 years ago by
| Owner: | changed from team to bagage |
|---|---|
| Status: | new → needinfo |
comment:3 Changed 5 years ago by
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 Changed 5 years ago by
| 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 Changed 5 years ago by
OK fair enough - it'll now use the --language=en option instead to avoid any troubles. Thanks!
comment:15 Changed 23 months ago by
Hmm, maybe we should catch this error and tell users not to use mismatching encoding specifications?
comment:16 Changed 23 months ago by
There is no JOSM code involved in the stacktrace, I don't know if we can catch the error.
comment:17 follow-up: 18 Changed 23 months ago by
We could output a warning at startup when JOSM is launched with LANG=C. Is there any good reason to do so?
comment:18 Changed 23 months ago by
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 Changed 18 months ago by
| Cc: | dbf added |
|---|
comment:35 Changed 13 months ago by
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 Changed 10 months ago by
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 Changed 10 months ago by
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 Changed 10 months ago by
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 Changed 10 months ago by
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 Changed 10 months ago by
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
From #14068 comments can you please try with
--language=encommand-line argument?