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:
parent
38e97b179c
commit
9122dc64fa
|
@ -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;
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue