[solved]BUG exists in batch rename features

[telanx]

Using win7 SP1 x64 Ultimate Edition
everything version: V1.4.1.935 (x64)

The text file has spaces in the file header after using batch rename, and it has no content when opened.

When you use Explorer to rename and delete the header space, it prompts that a file with the same name exists in the same directory.Using es can delete the header space without prompting errors.

Header spaces will be auto discarded when using Explorer to rename, while es will not. This may be the cause of the bug.

[NotNull]

How can we reproduce this issue?

[telanx]

How can we reproduce this issue?

Very simple, use es to add spaces before the file name, this is not allowed in Explorer, but es works.

[telanx]

There are some additions, the content is not displayed after opening the file because I used the VIM editor, and later I found out that it can be opened with notepad and have content, it seems that it is just a system naming conflict.
Sorry to disturb you. This can be over.

[NotNull]

Glad you got it working again!

Filenames that start with spaces, like " something.txt" are actually allowed in Windows.
I didn't know File Explorer had problems creating such a file. Learned something new

I think you can open your " something.txt" in VIM too, when you specify your command like this:
(enclose program as well as filename in "")

Code: Select all

"c:\path to\your vim editor.exe"  "    something.txt"

[telanx]

Glad you got it working again!

Filenames that start with spaces, like " something.txt" are actually allowed in Windows.
I didn't know File Explorer had problems creating such a file. Learned something new

I think you can open your " something.txt" in VIM too, when you specify your command like this:
(enclose program as well as filename in "")

Code: Select all

"c:\path to\your vim editor.exe"  "    something.txt"

Opening by right-click or cmd is no content, the path parameter already contains quotes.

In another case, when opening a file with a head space in vscode, right-click also failed and could not be opened. Use ctrl-o to open without problems.

So this is indeed a bug in win7 system processing files with spaces in the head.

[telanx]

Wait, I'm still not sure, I want to recheck my registry parameter problems. This bug looks very subtle ...

[telanx]

Thank you for your help, this problem looks like a very subtle win7 bug, I don't want to study it anymore, headache.

[therube]

(I just saw something interesting.
Changing [or adding] a files' extension [in Windows Explorer, or Salamander, & I'm sure elsewhere] causes it to drop its [leading] spaces.

Code: Select all

DIR > "  test"

"  test"     -> "test.txt'
"  test.doc" -> "test.txt"

Everything maintains the spaces when renaming.)

[therube]

Opening by right-click or cmd is no content, the path parameter already contains quotes.

No, I'm thinking it is the path-part that you're failing on (with vim - when the name-part includes preceding spaces).

Code: Select all

gvim  "!\\  test.txt"

The (shortened example I used) \\ escapes the path part (separator), so that vim knows your path-part is !\, followed by the name-part, which is <sp><sp>test.txt.

Without the escaping, vim treats the name-part as "! test.txt".

[telanx]

Opening by right-click or cmd is no content, the path parameter already contains quotes.

No, I'm thinking it is the path-part that you're failing on (with vim - when the name-part includes preceding spaces).

Code: Select all

gvim  "!\\  test.txt"

The (shortened example I used) \\ escapes the path part (separator), so that vim knows your path-part is !\, followed by the name-part, which is <sp><sp>test.txt.

Without the escaping, vim treats the name-part as "! test.txt".

Great! You're right! Insert two '\' in front of leading space file name to read successfully!
But using the same form, vscode also cannot be opened......
I want to ask, How should I replace "% 1" in .reg to avoid this kind of error? Any idea?
I found that vim also has this problem when the file name contains a '`' symbol in front of it.
I need to think about 'default program open' and 'right-click open' how modify the registry.
Thanks again for your thinking.

[telanx]

I think an easy way is to not insert spaces or other special symbols in front of the file name. This will cause trouble.

[telanx]

Opening by right-click or cmd is no content, the path parameter already contains quotes.

No, I'm thinking it is the path-part that you're failing on (with vim - when the name-part includes preceding spaces).

Code: Select all

gvim  "!\\  test.txt"

The (shortened example I used) \\ escapes the path part (separator), so that vim knows your path-part is !\, followed by the name-part, which is <sp><sp>test.txt.

Without the escaping, vim treats the name-part as "! test.txt".

'edit with vim' was added when the program was installed, and I tried to find its items in the registry, and why it works fine.
The left file in the picture has leading spaces. When opened with 'edit with vim', both can display content.

[therube]

The Vim registry entry, viewtopic.php?p=15973#p15973, looks like the VS Code entry.
Gvim works fine from the context-menu ('Edit with Vim') with files that have leading spaces.
With Vim open (with a different file), you can also edit a "spaced" file, again so long as you ESC the path part.
So, 'e: !\\ test.txt', will load " test.txt" (from within the ! directory).

I'm not familiar with VS Code so not sure why that wouldn't be working?


I can't tell from your screenshot, but in the VS Code registry entry, confirm there is no trailing space on the "%1" (vs "%1 ").

[NotNull]

(I just saw something interesting.
Changing [or adding] a files' extension [in Windows Explorer, or Salamander, & I'm sure elsewhere] causes it to drop its [leading] spaces.

It's even worse:
When you copy " spaces.txt" to a different folder using File Explorer, the result is "spaces.txt" !!
(at least on Win10)

I just downloaded and installed gvim as I was curious.
(G)vim uses dyanamic verbs through a COM object (HKCR\*\ShellEx\ContextMenuHandlers\gvim) so for all filetypes there is a Edit with gvim in the context-menu.
gvim doesn't associate itself with the Open verb, so that was done manually. That can be fixed (if you want help with tat, let me know), but what I really wanted to mention:

Gvim parses and expands the filename (including path) causing these problems.
Start gvim like this instead:

Code: Select all

"c:\path to\gvim.exe"  --literal "c:\Users\CYAN\!\     spaces.txt"

The --literal is key here

Works here

[telanx]

(I just saw something interesting.
Changing [or adding] a files' extension [in Windows Explorer, or Salamander, & I'm sure elsewhere] causes it to drop its [leading] spaces.

It's even worse:
When you copy " spaces.txt" to a different folder using File Explorer, the result is "spaces.txt" !!
(at least on Win10)

I just downloaded and installed gvim as I was curious.
(G)vim uses dyanamic verbs through a COM object (HKCR\*\ShellEx\ContextMenuHandlers\gvim) so for all filetypes there is a Edit with gvim in the context-menu.
gvim doesn't associate itself with the Open verb, so that was done manually. That can be fixed (if you want help with tat, let me know), but what I really wanted to mention:

Gvim parses and expands the filename (including path) causing these problems.
Start gvim like this instead:

Code: Select all

"c:\path to\gvim.exe"  --literal "c:\Users\CYAN\!\     spaces.txt"

The --literal is key here

Works here

awesome, I've tested that using the '--literal' parameter opens the path correctly.

Windows does have problems with file paths that contain Spaces or special characters.
explorer, CMD, and powershell all have this problem.
Thanks for your method, simple and effective.

[telanx]

The Vim registry entry, viewtopic.php?p=15973#p15973, looks like the VS Code entry.
Gvim works fine from the context-menu ('Edit with Vim') with files that have leading spaces.
With Vim open (with a different file), you can also edit a "spaced" file, again so long as you ESC the path part.
So, 'e: !\\ test.txt', will load " test.txt" (from within the ! directory).

I'm not familiar with VS Code so not sure why that wouldn't be working?


I can't tell from your screenshot, but in the VS Code registry entry, confirm there is no trailing space on the "%1" (vs "%1 ").

That's true. Open one of the correct files and then open the leading space file through another buffer, vim correctly reads the path.
Thanks to your valuable experience, I still don't quite understand the role of some registry keys.
Learned something from your answer.

[NotNull]

I would not expect this to fix your "double-click a txt file" issue. Did it?

BTW: CMD and PowerShell don't have problems with spaces in filenames. I used those to create and copy them.
(they do have issues with other special characters, especially CMD; In PowerShell you can use 'filename' (single quoted) for a literal filename, escaping toxic characters.

[telanx]

I would not expect this to fix your "double-click a txt file" issue. Did it?

BTW: CMD and PowerShell don't have problems with spaces in filenames. I used those to create and copy them.
(they do have issues with other special characters, especially CMD; In PowerShell you can use 'filename' (single quoted) for a literal filename, escaping toxic characters.

Yes, it also solves the problem of double-click opening without content.

Code: Select all

@echo off
setlocal EnableDelayedExpansion
set p=%_VIM%\vim82\gvim.exe --literal "%%1"

ftype txtfile=%p%
ftype inifile=%p%

assoc .vimrc=vimrc
ftype vimrc=%p%
assoc .vim=vimfile
ftype vimfile=%p%
assoc .md=mdfile
ftype mdfile=%p%
assoc .cpp=cppfile
ftype cppfile=%p%

I created a batch script that can modify the value of 'HKCR\txtfile\shell\open\command', but still set the default program by content menu. Then it can read the path correctly.
I've written a few little ps1 scripts before, I'm annoyed by the symbol and character error. So...
and sorry, English is poor.

[NotNull]

Ah, that explains it! That will work

So, everything (and "Everything") OK now and I can uninstall gvim again?

(Nothing wrong with your English, btw)

P.S. And don't forget these registry keys, as they overrule what you defined in your script:

Code: Select all

set "EXT=.txt"

:: Part 1
reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID

:: Part 2 (where PART 1 links to)
for /f "usebackq tokens=2,*" %x in (`reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID`) do reg.exe query "HKCR\%y" /s

(
I think I don't need to tell you, but ...
If you want to run this from a script (instead of a command-line) double the % in %x and %y : %%x and %%y
)

[telanx]

Ah, that explains it! That will work

So, everything (and "Everything") OK now and I can uninstall gvim again?

(Nothing wrong with your English, btw)

P.S. And don't forget these registry keys, as they overrule what you defined in your script:

Code: Select all

set "EXT=.txt"

:: Part 1
reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID

:: Part 2 (where PART 1 links to)
for /f "usebackq tokens=2,*" %x in (`reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID`) do reg.exe query "HKCR\%y" /s

(
I think I don't need to tell you, but ...
If you want to run this from a script (instead of a command-line) double the % in %x and %y : %%x and %%y
)

COOL!
I finally understand how to double-click open the program with registry modification. As you said!
Modifying the key value of "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice\Progid" is "txtfile" !(If it is not using ps1, it needs to modify the permissions.)
And content menu changes default program this step can be removed!
Thanks for the code and experience, Ps1 scripts use for loop to modify the registry is really elegant and simple!
vim is very powerful and recently tried vscode, it is very convenient, comes with perfect coding features, but can not replace vim.
BTW, What editor do you usually use?

[NotNull]

BTW, What editor do you usually use?

I mostly do rather simple editor stuff (more than 100 lines is an exception), so I'm happy with Notepad++ and Notepad.
(80% / 20% of the time).

I also tried VS Code (for PowerShell scripts), but that is almost half a gigabyte in size (Notepad++: 20MB, including plugins) and starts too slow if you want to do a quick edit.
Other than that: a very powerful editor.

No experience with gvim, other than the 10 minutes I looked at it yesterday.

[telanx]

BTW, What editor do you usually use?

I mostly do rather simple editor stuff (more than 100 lines is an exception), so I'm happy with Notepad++ and Notepad.
(80% / 20% of the time).

I also tried VS Code (for PowerShell scripts), but that is almost half a gigabyte in size (Notepad++: 20MB, including plugins) and starts too slow if you want to do a quick edit.
Other than that: a very powerful editor.

No experience with gvim, other than the 10 minutes I looked at it yesterday.

VIM is also very fast to start. In fact, VIM's installation package is less than 9mb.
vscode as an IDE and editor, its startup speed and capacity are also quite excellent, but its mode of operation makes me unaccustomed.

[telanx]

Code: Select all

set "EXT=.txt"
:: Part 1
reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID
:: Part 2 (where PART 1 links to)
for /f "usebackq tokens=2,*" %x in (`reg.exe query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\%EXT%\UserChoice" /v ProgID`) do reg.exe query "HKCR\%y" /s

Sorry, this code is batch.
I usually change the registry manually. I'll improve this code later, and it will be very convenient next time.

[NotNull]

VIM is also very fast to start. In fact, VIM's installation package is less than 9mb.

Installed it was 28MB, IIRC. gvim started even faster than Notepad++.

I usually change the registry manually. I'll improve this code later, and it will be very convenient next time.

Note:
That will work because you are on Win7. On Win10 the UserChoice regkeys are protected against editing.
The HKCR\... keys can be edited though.

[telanx]

Note:
That will work because you are on Win7. On Win10 the UserChoice regkeys are protected against editing.
The HKCR\... keys can be edited though.

There is a way to modify permissions through the script. save the items and key-value pairs in .ini file, then use 'regini' command to read this file.
like this:

Code: Select all

regini.ini content:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice [21]
Progid = txtfile

But you still need a script to write the variables to ini, feel like a stupid way, but there's no way, maybe that's Microsoft's style

[NotNull]

Microsoft doesn't want you to mess with the UserChoice regkeys.
I you "go with the (Microsoft) flow", you right-click a - for example - .txt file > Open With > Choose another app and enable Always use this app to open txt files

Here is something that I wrote elsewhere on this forum:

Since Window 10 (and probably Win8), regular file associations are 'deprecated' (not the right word, but that's the best I got right now)
That's because Microsoft wants to prevent applications 'stealing' file extensions to protect the user.

Instead of that (*), there is now a UserChoice registry entry. The choice of the user can not be tampered with (includes a hash to check it's integrity) after it has been set.
Those keys can be found under HKCU\software\microsoft\windows\currentversion\explorer\FileExts.

(This version of) ShellExecuteEx does not 'honor' the UserChoice settings.

(Not that I mind; just a FYI)

(*) Not completely accurate .. If there is no UserChoice setting, the normal file associations are used; If there is a UserChoice setting, that one supersedes.

Anyway ... long story short ...
Turns out that this wasn't a bug after all .. wasn't an issue in Everything .. but unexpected behaviour of the gvim application. And got solved anyway!

Case closed, as far as I'm concerned

[telanx]

Anyway ... long story short ...
Turns out that this wasn't a bug after all .. wasn't an issue in Everything .. but unexpected behaviour of the gvim application. And got solved anyway!

Case closed, as far as I'm concerned

Although it was an accident, it helped me solve a long-standing problem.
THANK YOU SOOO MUCH, and @therube.

[NotNull]

*Especially* @therube, as he found the real reason why it didn't work as expected.

[therube]

Unless I'm misunderstanding, there is an overwrite dialog as expected when attempting to
rename " abc123" to "abc123".



(No option to overwrite, auto-rename, or anything like...)