Off the top, I'll mention that "Server completion" is disabled (set to "None") in the options.
I'm trying out TCC version 32.10.21 and I have an alias that, for demonstration sake, I simplified to this:
fver=echo %$ - %@verinfo[%$]
All it's doing is echoing the input and then grabs the @verinfo for it. I use this as a quick way to see if files on remote systems were upgraded or not.
In usage, I'll type something like "fver \\server01\c$\windows\system32\ntoskrnl.exe" and I get the expected result.
Then I up-arrow to bring that command up again and cursor over and the moment I start deleting or inserting characters in the server name, like I want to change it to server02, there's a long delay of a second or two each time I insert or delete a character.
I think I saw something similar in the old version I use (v24) but now I'm unsure about that.
Anyway, I fired up "Process Monitor" to see what activity tcc.exe was doing when I'm typing those new characters or deleting them, and it does a few things. For this example, this is what it did when I merely deleted the "1" on the end of that remote server name:
CreateFile for C:\windows\CSC\v2.0.6\namespace\server0
CreateFile for \\server0\c$
More of the CreateFile for the CSC namespace local folder
CreateFile for \\server0\c$\windows\system32
etc.
It goes through that several times, trying in vain to create file handles for the non-existent server name before timing out, and then I can do the next character.
It only seems to do this with an alias. In any other circumstance, like if I did an "echo %@verinfo[\\server01\c$\windows\system32\ntoskrnl.exe] directly and then started modifying that command line to specify a different server, it's super snappy and responsive. So it acts as if the alias itself is responsible for trying to do some on-the-fly lookups of whatever path I'm feeding it, which is a little odd.
I'll have to try this on my old v24... I rebuilt my system the other day and thought I'd give the latest TCC a spin and get myself upgraded after many years, so getting v24 back on there would be a little work but not bad. I just don't remember having that problem before, but it has been a while. The only reason it came up now is that I was doing manual checks of which servers applied (or not) the Server 2019 hotfix that Microsoft pulled earlier this month. :)
I'm trying out TCC version 32.10.21 and I have an alias that, for demonstration sake, I simplified to this:
fver=echo %$ - %@verinfo[%$]
All it's doing is echoing the input and then grabs the @verinfo for it. I use this as a quick way to see if files on remote systems were upgraded or not.
In usage, I'll type something like "fver \\server01\c$\windows\system32\ntoskrnl.exe" and I get the expected result.
Then I up-arrow to bring that command up again and cursor over and the moment I start deleting or inserting characters in the server name, like I want to change it to server02, there's a long delay of a second or two each time I insert or delete a character.
I think I saw something similar in the old version I use (v24) but now I'm unsure about that.
Anyway, I fired up "Process Monitor" to see what activity tcc.exe was doing when I'm typing those new characters or deleting them, and it does a few things. For this example, this is what it did when I merely deleted the "1" on the end of that remote server name:
CreateFile for C:\windows\CSC\v2.0.6\namespace\server0
CreateFile for \\server0\c$
More of the CreateFile for the CSC namespace local folder
CreateFile for \\server0\c$\windows\system32
etc.
It goes through that several times, trying in vain to create file handles for the non-existent server name before timing out, and then I can do the next character.
It only seems to do this with an alias. In any other circumstance, like if I did an "echo %@verinfo[\\server01\c$\windows\system32\ntoskrnl.exe] directly and then started modifying that command line to specify a different server, it's super snappy and responsive. So it acts as if the alias itself is responsible for trying to do some on-the-fly lookups of whatever path I'm feeding it, which is a little odd.
I'll have to try this on my old v24... I rebuilt my system the other day and thought I'd give the latest TCC a spin and get myself upgraded after many years, so getting v24 back on there would be a little work but not bad. I just don't remember having that problem before, but it has been a while. The only reason it came up now is that I was doing manual checks of which servers applied (or not) the Server 2019 hotfix that Microsoft pulled earlier this month. :)
