Recover installed plugins/configuration after TC crash

[geek4allseasons@hotmail.c]

After Total Commander crashed it the configuration for all installed plugins was lost.

Forum and Web searches didn't produce any useful information. The plugins look fine, happily tucked away just where they were.

Is there a program/tool to verify/rebuild lost config entries? I wasn't able to identify a .ini file. I believe the HKLM/Software/GHISLER registry key was trashed and recreated under HKCU.

This is a recent installation of TC 7.04a running on XP SP3 with all updates applied.

The builtin plugin manager isn't happy reinstalling a plugin. Hmm, I didn't notice the missing plugin configuration until today after a re-boot last night. It was late and I was not at the the top of my game.

If would be very help knowing if a recovery tool exists in any case. Manually re-installing will be time consuming. If there isn't one this experience has given some ideas for my first community contribution(s).

Any suggestions would be appreciated. Guess I should see what Plugin Manager and Vic Plugin manager have to say today.

[fenix_productions]

2geek4allseasons@hotmail.c

There is no recovery tool made specially for TC settings. Because they are stored in wincmd.ini file, the only way to get them back is trying some files recovery tools like Undelete.

[geek4allseasons@hotmail.c]

I'm afraid it's not a "computer ate my .ini file" problem.

I didn't select the default path option in the install dialogue. The Plugin Manager wasn't pointing to APPDATA so I muked around with its path settings. Then tried out the Vic Plugin Manager.

At that point I thought the Vic Plugin Manager was confused. I could see the plugin entries in %WINDIR%\wincmd.ini, but no matter how I set the paths it couldn't. It seems like a concurrency (or lake of it) issue.

It's clear my missing appendages are my own doing. I'm not sure as yet who is trampling on who yet. All paths are now set to WINDIR, including the registry.

The best story I could make up to explain the confusion is there is no "lock" on the .ini file. The plugin managers open the .ini files as new when the path is changed.

At least the Vic Plugin Manager does, because it seems to support multiple profiles. That's a useful feature given the plethora of plugins. It might play nicer if I stop twiddling with its path settings.

I guess the "live and learn" rule is in effect when the quality and/or quantity of documentation is not even close to that of the software.

TC is awesome! I can't believe I've been around the track as many times without learning how great/indispensable it is.

As far as a "tool" for rebuilding/repairing a plugin configuration .... "never mind". I've been spending far too much time trying to make sense of Windows.

The pluginman.exe command line, a list of plugin file paths and a simple script will automate recovery. The mass-install from an archive is a great feature if all plugins had plugindef.inf files.

I found a lot that don't and others that are .exe addons. My ignorance is probably showing .... again.

Thanks for the reply. Eventually, I'll hack my way through. I can't count the number of prior exercises where I end up looking like the Black Knight at the bridge in one of Monty Pythons movies.

[petermad]

2geek4allseasons@hotmail.c

If you have all your plugins installed in subdirs of one common plugins dir, then you can easily reinstall them all using TC Plugins Manager 2.0.1 http://www.totalcmd.net/plugring/tc_plugman.html

Just chose "Install" -> "Install from folder..." adn point to your main plugins folder.

[geek4allseasons@hotmail.c]

2geek4allseasons@hotmail.c

If you have all your plugins installed in subdirs of one common plugins dir, then you can easily reinstall them all using TC Plugins Manager 2.0.1 http://www.totalcmd.net/plugring/tc_plugman.html

Just chose "Install" -> "Install from folder..." adn point to your main plugins folder.

Guess that's another "DUH!" on my part. A big one. I checked all Plugin Manager pages. They clearly say "nested folders". I often wonder just what was I thinking. Or NOT.

I did benefit from repeated visits to plugin folders. It gave me a rough idea of the range of implementations. Your comment reminded me that I didn't use all available resources. Most notably the Wiki.

The short time I poked around I didn't find much consolidated install information. It appears that pages linked to on the main install page do not reflect changes in recent versions.

The page describing the pluginst.inf was the most helpful. It is lean and tightly focused on plugins. Comments indicate that is intended and represents a community consenous.

As yet I have not found any guidelines and/or support tools for addons. TC is an open architecture. That is a very good thing. I think there is an important connection to Perl. Larry Wall has said that language was intentionally not designed (until Perl 6).

That idea would make an effete Context-Free Grammar/Language Theory snob breakout in a sweat. In hard core cases a rash or more sever histaminic reactions.

It reflects his Natural Language/Linguistics background and allowed the language to evolve freely and become an enormously productive feature rich platform.

Paraphrasing Spiderman (actually his uncle) "with great power comes great responsibility". Flexibility does make it easier to slit your throat. In the real world diagnostics, testing and debugging tools do the heavy lifting.

Big languages haven't been very successful. P/L 1 is an example. C is the other end of the spectrum. A small canonical language supporting abstraction extended through libraries.

Perl is made up of "syntactic sugar" (another Larry-ism). It's Lisp with a friendly face(s). There is a small core implementation. It is most commonly extended through libraries ala C.

They don't have to be Perl libraries. Well, you say that's nothing special. C and other languages can inter-operate if they use the same calling conventions and/or can be "glued" together.

There is another type of Perl extension that adds new syntax and/or changes the semantics of core constructs. They were uncommon in Perl 4. Have become increasingly more common in Perl 5. The mechanism/interface has been formalized and is now a primary mean of extending/implementing new core language features.

Fine grained adaptability and extensibility has been built in the architecture and implementation of Perl 6. The Eclipse IDE is similarly composed of modules with well defined interfaces. Applications are dynamically assembled using configurations composed of descriptions conforming to the OSGi standard.

So what does the above have to do with Total Commander plugin development? The pluginst.inf format can be viewed as a mini-language plugin description language.

Without seeing a line of code implementing Total Commander it is evident that it has a well defined architecture and implementation. It should be possible to create other mini-languages.

Not having explored the Wiki much it occurs to me I may be spouting about old news. That usually doesn't stop me. This message has taken on a life of its own. (not bad blame it on the message ).

Some useful small steps toward that end would be elaborating the current plugin classifications both functionally and structurally, create a parrallel categorization of addons. Enumerations/descriptions of TC extension/integration points could be derived from API documentation. If it isn't in the Wiki already consensus views on TC extension best practices, idioms, guidelines and patterns.

Any thoughts? What have I missed? Is any of it relevant?