notepad-plus-plus
notepad-plus-plus copied to clipboard
Regression bug: Open new file c:\test\test. (including a dot at the end)
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
- 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: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/12613 The error should only happen with other namespaces like \\?\, not when the normal namespace c:... is used.
@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.
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".
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.
@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 ?
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 underc:\test\test.txt
If you enter the namec:\test\test.
, it will be saved underc:\test\test
@white-gthb
Press Ctrl+N Type some text Press Ctrl+S If you enter the name
c:\test\test
, it will be saved underc:\test\test.txt
If you enter the namec:\test\test.
, it will be saved underc:\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
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
.
@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.
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.
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
@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.