Regression bug: Open new file c:\test\test. (including a dot at the end)

[white-gthb]

Description of the Issue

Trying to create a new file by executing Notepad++ c:\test\test. fails with error Cannot open file "c:\test\test.".

Steps to Reproduce the Issue

1. Execute Notepad++ c:\test\test.

Expected Behavior

Same behavior as when using a relative path: show the dialog:

Create new file
"c:\test\test" doesn't exist. Create it?
Yes No

Actual Behavior

Error Cannot open file "c:\test\test.". is shown.

Debug Information

Notepad++ v8.4.8 (64-bit)
Build time : Dec 24 2022 - 19:40:27
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : c:\test\test.
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 11 (64-bit)
OS Version : 22H2
OS Build : 22621.1105
Current ANSI codepage : 1252
Plugins :
DSpellCheck (1.4.24)
HexEditor (0.9.12)
mimeTools (2.9)
NppConverter (4.5)
NppExport (0.4)

When you set Notepad++ to be your external editor in Total Commander, creating a new file (Shift+F4) with a filename without extension, no longer works. It did before.

Using a relative path does work. Examples:
Using WIndows Run: Notepad++ ..\..\test\test.
Using Command Prompt: cd /d c:\test & start Notepad++ test.

Notepad++ \test. also fails.

I believe this regression is caused by this fix: #12613
The error should only happen with other namespaces like \\?\, not when the normal namespace c:... is used.

[donho]

@white-gthb
It's not a regression to me. If you want to open such unconventional file, use Win32 Namespace prefixed file name:
Notepad++ \\?\c:\test\test.

[white-gthb]

You misunderstood. In the normal namespace this simply means a filename without filename extension, not a filename that ends with a dot. So I wish to create "c:\test\test" without any dot. Total Commander sends "c:\test\test." to the editor because some editors would otherwise create "c:\test\test.txt".

[white-gthb]

Note what I wrote as expected behavior (which is what you get if you use a relative path). There's no dot there.

It's perfectly normal to use this notation in normal namespace. In Notepad++ you use that too if you create a new file (Ctrl+N) and then save it to a filename without filename extension.

[donho]

@white-gthb

In Notepad++ you use that too if you create a new file (Ctrl+N) and then save it to a filename without filename extension.

I cannot reproduce that. Could you provide step by step instructions ?

You misunderstood. In the normal namespace this simply means a filename without filename extension, not a filename that ends with a dot. So I wish to create "c:\test\test" without any dot. Total Commander sends "c:\test\test." to the editor because some editors would otherwise create "c:\test\test.txt".

What do you think about it @xomx ?

[white-gthb]

In Notepad++ you use that too if you create a new file (Ctrl+N) and then save it to a filename without filename extension.

I cannot reproduce that. Could you provide step by step instructions ?

@donho

• Press Ctrl+N
• Type some text
• Press Ctrl+S
• If you enter the name c:\test\test, it will be saved under c:\test\test.txt
  If you enter the name c:\test\test., it will be saved under c:\test\test

[alankilborn]

@white-gthb

Press Ctrl+N
Type some text
Press Ctrl+S
If you enter the name c:\test\test, it will be saved under c:\test\test.txt
If you enter the name c:\test\test., it will be saved under c:\test\test

The behavior is going to depend upon the state of this checkbox:

If the checkbox is checked, the behavior you describe is obtained.

If the checkbox is unchecked, in both of your cases you will obtain c:\test\test

[mpheath]

I believe this regression is caused by this fix: #12613

The code linked considers that there is only 2 wildcard characters * ? and considers any other wildcard character as an invalid character. There are actually 5 wildcard characters * ? < > " .

https://learn.microsoft.com/en-us/archive/blogs/jeremykuhne/wildcards-in-windows

path normalization eats trailing periods and spaces

So test. becomes test .

[xomx]

@donho
Sorry, as I told you, I cannot get involved here for some time (thanks for understanding, more via e-mail later).
I will try to keep at least my translation up-to-date when possible.

@white-gthb
Your observation in this issue is correct.
In the #12613 I clearly stated that it needs further patches otherwise some stuff will not work.
Windows shell and some corresponding WINAPIs mangles such nonstandard filenames by cutting off the ending periods and spaces, like @mpheath said. Before I had to interrupt my consequent work on this, I have got a hacked N++ version where I could even use the "\\?\C:TEST\test." notation in the N++ Open/SaveAs dlgs and your STR worked as you expected. I will see what I can do about it, but now I cannot promise anything.

@mere-human
I played with your Vista+ IFileDialog based N++ file Open/Save dialogs stuff, but could not find an equivalent of the OFN_NOVALIDATE flag, which I need for support of the following notation:

There is the FOS_NOVALIDATE, but unfortunately this is NOT the equivalent of the previous flag!

I tried dirty hack and replaced the current COM based file Open/Save dlgs in N++ with the previous GetOpenFileName/GetSaveFileName way with the OFN_NOVALIDATE set and has been able to work even with the "\\?\C:\TEST\file." notation and this issue STR then behaves as expected (i.e. created a new file without the ending period).

Could you please look at it? Maybe I overlooked something.

[mere-human]

I played with your Vista+ IFileDialog based N++ file Open/Save dialogs stuff, but could not find an equivalent of the OFN_NOVALIDATE flag, which I need for support of the following notation:

Hi @xomx

Why do you need that?
The bug description is about the opening file from command line.
I tried the test scenario. In 8.4.7 it works as expected. So it looks like a regression.

I don't understand how open and save dialogs are related.

[white-gthb]

Total Commander users who configured Notepad++ as external editor regularly run into the problem of this issue. Two examples on the Total Commander forum:

• https://ghisler.ch/board/viewtopic.php?t=78776
• https://www.ghisler.ch/board/viewtopic.php?t=78947

[xomx]

@white-gthb
I owe you an apology here. Before, I read your issue too quickly and evidently did not fully understand it. Now I think I can fix this specific issue with a very simple PR. Will try.