Weird crash on viewing txt file

[solid]

I've come across a weird situation where Total Commander (TC) crashes without any error message when I press F3 (Lister) on one of several text files in the folder "D:\My documents". However, when I copy any of those files to another folder or subfolder of this folder, the Lister opens and shows the file without any issues. After returning the file to the original folder, TC crashes again on pressing F3.

If I press ALT+SHIFT+F3, the Lister opens fine. However, if I press 4 while in Lister, both TC and Lister disappear immediately. TC also crashes in thumbnail view whenever any of these files are displayed.

This issue occurs only on TC x64 and not on TC32. Also TC x64 with a fresh INI file works fine. I am using Windows 10 x64 and the latest version of TC (10.52). I also face the same problem on another computer with the same TC.

Therefore, the cause seems to be in my current configuration. Could you please suggest the possible reasons for this weird behavior, and how I can pinpoint the problem?

[white]

What's the filename extension of the text files? .txt ? What happens when you rename them to .txt2 ?

[Dalai]

This sounds like it's caused by a Lister plugin. Disable them one by one to find the one causing this. Maybe start with the plugin that's likely to be used for the file type you're trying to open. Consult Options > Plugins > Lister plugins to see which one(s) that could be.

Regards
Dalai

[beb]

I suppose it may happen if the permissions are broken.
To reset [repair] permissions:

Code: Select all

icacls "D:\My documents" /reset /t /c /l /q 2>>icacls_permissions.log

NB https://ss64.com/nt/icacls.html

[solid]

Hmm, this is just getting weirder.

If I rename to .txt2 it opens, no crash.
Further testing shows that filename length or pathname length matters.
If I remove one character form filename and keep .txt2 extension it crashes again.
So far it happens if filename with extension has 20 chars (36 with the whole path)
It happens on ANY file that opens as text file, that has this filename length, regardless of length of extension.

I'll investigate further and I'm open to any ideas.

[solid]

I've noticed that TC crashes when the path with filename length is 36 characters, irrespective of the folder.
The plugin responsible for the crash is ArchView (http://totalcmd.net/plugring/archview64.html).

I am unsure why this issue occurs only in this specific case and how this plugin affects non-archive file types. The issue manifests for all file types that do not open with any other plugin.

I'll try to find the problem. Thanks for everyone trying to help, I wouldn't came so far so fast without your suggestion.

[Dalai]

I've noticed that TC crashes when the path with filename length is 36 characters, irrespective of the folder.

That is very specific and as such really strange.

The plugin responsible for the crash is ArchView (http://totalcmd.net/plugring/archview64.html).

Interesting.

I am unsure why this issue occurs only in this specific case and how this plugin affects non-archive file types.

The explanation is simple: This particular plugin doesn't set a _detect string (you can see in wincmd.ini, section [ListerPlugins], that it's absent for this plugin). The result of this is that Lister will try to open any file with this plugin by default. From looking at the Template.ini this plugin ships with I guess that the plugin explicitely disables returning a _detect string to TC by default:

Code: Select all

[Main]
SetDetectString=0

I've just discovered that this plugin creates its own log file by default. It's created in the directory where the plugin is installed [1]. It might get you some clue as to what exactly is going on.

[1] Logging features are good in general, but I don't get why plugin authors think it's a good idea to write to the plugin directory.

Regards
Dalai

[solid]

2Dalai
The log file isn't providing any useful information in this case.

I recently installed this plugin as a replacement for ArcView, which doesn't have a 64-bit version

Would anyone be willing to test this issue and confirm it?
If it's indeed a problem, we can report it to the plugin author for resolution.

[Horst.Epp]

Why not just making an detect string with the aarchive extensions you need ?

[Dalai]

2solid
Honestly, I would report the issue to the author anyway. I did some quick tests with this plugin yesterday and experienced some weird behavior, including some TC crashes. It was similar to the things you observed but not exactly the same (which might be due to differences in OS and other factors).

2Horst.Epp
That will probably fix the issue for text files but I doubt it's going to change anything about archive files.

Regards
Dalai

[solid]

Why not just making an detect string with the aarchive extensions you need ?

I did that, but as Dalai pointed out, it doesn't completely address the issue for archives with this specific path length.
Also it seems there are other factors that causes the crash.