Summary

On Linux, you cannot save a received file whose name contains [, *, or ? — the Save dialog stays open and nothing is written to disk. Reproduced with [test].txt; common in practice with browser-style downloads like report[1].pdf.

Root cause

javax.swing.plaf.basic.BasicFileChooserUI.ApproveSelectionAction.actionPerformed() does this when the user clicks Save:

1. reads the typed filename via getFileName()
2. resolves it via FileSystemView.createFileObject(name)
3. if the file does not exist AND isGlobPattern(name) is true, it interprets the name as a glob: it calls changeDirectory(parent), sets a GlobFilter on the chooser, and returns — without ever calling approveSelection().

BasicFileChooserUI.isGlobPattern() (verified by reflection on JDK 17.0.18):

So file[1].pdf → isGlobPattern true → glob branch taken → save never happens. On Windows [ is not a glob char per the JDK; on macOS this code base uses java.awt.FileDialog, not JFileChooser, so neither is affected by the [ case. (* and ? are also intercepted as glob in the JFileChooser save dialog on Windows, but they are illegal NTFS filename chars anyway.)

When this regressed

Introduced by 02d0094 / #2789 (2023-07-28, "desktop: fix creating tmpDir and providing name for file to save"). That commit started pre-populating the filename via:

fileChooser.selectedFile = File(filename)

Before then, the save dialog ran in DIRECTORIES_ONLY mode — the user picked a folder and the file was written with its original name; JFileChooser never saw the filename, so the glob branch never ran.

Fix approach

BasicFileChooserUI.getApproveSelectionAction() is a public method that returns the exact ActionListener instance wired onto the Save button. Using that we:

• locate the Save button by identity (it === listener) — no class-name string match;
• replace it with a small handler that resolves the typed text as a literal filename, traverses on directory paths, and calls approveSelection() directly — bypassing the glob branch entirely.

The handler is installed only when !isLoad && desktopPlatform.isLinux():

• Windows save dialog: untouched.
• macOS save dialog: untouched (uses java.awt.FileDialog, different code path).
• Open dialog on every platform: untouched (the fix is gated on !isLoad).

Why bypass glob-on-save entirely (instead of only for [)

JFileChooser's glob-on-save behaviour is a Swing-only eccentricity that no native OS save dialog implements:

• macOS NSSavePanel — no glob-on-save (and this app already uses it on macOS via AWT FileDialog).
• Native Windows save dialog — no glob-on-save.
• Native Linux GTK / KDE save dialogs — no glob-on-save.

It also blocks legitimate POSIX filenames containing * or ? from being saved (those are legal on POSIX filesystems even though Windows forbids them).

So the user-facing change on Linux is: the Save button always treats the typed text as a literal filename — matching what users get on macOS in this same app and what they get from every native OS save dialog.

Alternatives considered and rejected

Test plan

• Build Linux AppImage; receive [test].txt, click Save → saves correctly.
• Save filenames containing * and ? on Linux → save correctly.
• Save normal filename hello.txt → unchanged behaviour.
• Save into a directory by typing its path in the filename field → traverses into it.
• Confirm Windows save dialog unaffected (no code path change for Windows).
• Confirm macOS save dialog unaffected (no code path change for macOS).
• Confirm open dialog unchanged on every platform.