----------------------------------------
d - lock failed!!!!!!!!!!!!!!!!!
d - request lock
d - locked
d - request lock
d - lock failed!!!!!!!!!!!!!!!!!
d - request lock
d - locked
d - request lock
d - lock failed!!!!!!!!!!!!!!!!!
d - request lock
d - locked
d - request lock
d - lock failed!!!!!!!!!!!!!!!!!
n - request lock
n - locked
t - request lock
t - locked
s - request lock
s - locked
j - request lock
j - locked
n - request lock
n - locked
t - request lock
t - locked
s - request lock
s - locked
...
Is it created by TC?
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
Thanks for the info but this is not my case. I thought it might be TC because this file has started appearing the last few months, after i started using TCpb1. Anyway, Christian will certainly know!
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
2wanderer
Is the file still changing? Process Explorer can give you a hint, which program has it open. And there is FileMon as well.
I severily doubt, that Christian will grab his hair screaming oh, no! i left some debug info in the TC release!
I switched to Linux, bye and thanks for all the fish!
SanskritFritz wrote:2wanderer
Is the file still changing? Process Explorer can give you a hint, which program has it open. And there is FileMon as well.
I severily doubt, that Christian will grab his hair screaming oh, no! i left some debug info in the TC release!
Me too, but you never know. Since there is a "treeinfo.wc" file, why not a "treeinfo.txt"? And after all, TC is still in beta phase so...
Whenever i notice this file, it happens to have a creation date of at least 2-3 hours behind. Apparently it is created under certain circumstances that do not occur very often. When i delete it, it just gets deleted without any delays (so no app has it locked). It is not recreated after a while, not even after i reboot the PC. There is no indication of an application using it. It seems it's created under some circumstances, the app writes some lines in it and then it closes it and that's all.
Anyway...
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
2wanderer
As I don't see anything like this with my TC I can only suggest:
1. run TC with a fresh wincmd.ini for a while,
2. monitor explorer.exe actions also,
3. check for services and shell extensions other than those that come in Windows by default,
4. compare totalcmd.exe integrity with the original exe found in the installation setup
Dark-Star wrote:The question is: Why does it get activated on your system, but not on anyone else's?
Good question . It happens randomly. This time i had opened 1 instance of TC at some point, a second instance after about 1 hour and i was working on the second instance in several tabs in both local and network drives. I'm guessing it has something to do with the refresh of the separate tree. I have 1 sep tree always open.
- Wanderer -
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Normally using latest TC on:
x32: WinXPx32 SP3 (very rarely nowadays).
x64: Clients/Servers - Win10/Win11 and Win2K16 to Win2K22, mainly Win10 though.
Seems like debugging stuff. The question is: Why does it get activated on your system, but not on anyone else's?
I am just wondering... what did you use to find such "strings" in totalcmd.exe? If Lister in Hex view is the answer, then I must say that its hex search algorithms don't look too sane IMO.
On the right side (ASCII view) of the hex view you should see 'treelog.txt', which is not the case, Lister shows 2 garbage characters.
roentgen wrote:I am just wondering... what did you use to find such "strings" in totalcmd.exe?
You either have to unpack TC with UPX (or get the unpacked version from the site) or you have to search within the running process (eg with Process Explorer).
Indeed this file is created when acessing the separate tree fails, for example because it is locked by a background thread. This can happen when updating the tree takes a very long time. I will remove this debugging function from the next beta.