#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: |
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 (23)
comment:1 Changed 3 years ago by
| Keywords: | linux added |
|---|
comment:2 Changed 3 years ago by
| Owner: | changed from team to bagage |
|---|---|
| Status: | new → needinfo |
comment:3 Changed 3 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 3 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 3 years ago by
OK fair enough - it'll now use the --language=en option instead to avoid any troubles. Thanks!
comment:15 Changed 3 months ago by
Hmm, maybe we should catch this error and tell users not to use mismatching encoding specifications?
comment:16 Changed 3 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 3 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 3 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.
From #14068 comments can you please try with
--language=encommand-line argument?