Fix rejection of the standard filenames with dot at the end (regression)

Currently we cannot accept e.g. the "\\?\C:\file.", but when someone tries to open the standard variant 'C:\file.', we should accept that, as this is the way how to work with filenames without an extension.

Fixes #12849, close #13888
This commit is contained in:
xomx 2023-07-12 11:40:22 +02:00 committed by Don Ho
parent 38e97b179c
commit 9122dc64fa
1 changed files with 5 additions and 1 deletions

View File

@ -1549,7 +1549,11 @@ bool isUnsupportedFileName(const generic_string& fileName)
// possible raw filenames can contain space(s) or dot(s) at its end (e.g. "\\?\C:\file."), but the Notepad++ advanced // possible raw filenames can contain space(s) or dot(s) at its end (e.g. "\\?\C:\file."), but the Notepad++ advanced
// Open/SaveAs IFileOpenDialog/IFileSaveDialog COM-interface based dialogs currently do not handle this well // Open/SaveAs IFileOpenDialog/IFileSaveDialog COM-interface based dialogs currently do not handle this well
// (but e.g. direct Notepad++ Ctrl+S works ok even with these filenames) // (but e.g. direct Notepad++ Ctrl+S works ok even with these filenames)
if (!fileName.ends_with(_T('.')) && !fileName.ends_with(_T(' '))) //
// Exception for the standard filenames ending with the dot-char:
// - when someone tries to open e.g. the 'C:\file.', we will accept that as this is the way how to work with filenames
// without an extension (some of the WINAPI calls used later trim that dot-char automatically ...)
if (!(fileName.ends_with(_T('.')) && isWin32NamespacePrefixedFileName(fileName)) && !fileName.ends_with(_T(' ')))
{ {
bool invalidASCIIChar = false; bool invalidASCIIChar = false;