Why do we need a new file "tcDirFrq.txt"?

[funkymonk]

TC11.00b1

Not really a bug, but I also don't see it as a suggestion. More like a discussion on TC11:

Why is there a need for an extra file "tcDirFrq.txt"?
Why can't the contained information just be stored in the regular TC ini file (just like recent search strings, left/right history, etc.)?

Imho, creating a new file for this information just clutters the centralized and clean ini-concept of TC.
If someone really needs/wants a separate file for the folder access frequencies, there is still the option to use RedirectSection.

[Galizza]

Imho, creating a new file for this information just clutters the centralized and clean ini-concept of TC.
If someone really needs/wants a separate file for the folder access frequencies, there is still the option to use RedirectSection.

Totally agree.

[zhugecaomao]

TC11.00b1

Not really a bug, but I also don't see it as a suggestion. More like a discussion on TC11:

Why is there a need for an extra file "tcDirFrq.txt"?
Why can't the contained information just be stored in the regular TC ini file (just like recent search strings, left/right history, etc.)?

Imho, creating a new file for this information just clutters the centralized and clean ini-concept of TC.
If someone really needs/wants a separate file for the folder access frequencies, there is still the option to use RedirectSection.

Agreed~

[AntonyD]

I support you very much. Especially considering the fact that in a convenient GUIsettings there are no place for changing the path to this file by mouse. Everything must be done manually in the INI file directly. Well, at least it turned out that there is an option to disable this "feature". True, in a very non-intuitive place. And in general it is not clear - why should the context menu be displayed for the list of folders from the history of their visit?

[funkymonk]

BTW: In combination with RedirectSection, storing the folder access frequencies with TC's regular ini-concept can be

1. easily outsourced even to a computer-specific file (for portable TCs);
2. easily disabled by simply setting the read-only attribute for the referenced file.

[norfie²]

The reason for this could be the different format of the entries and the different coding of the files.

[ghisler(Author)]

The new location under Appdata\local is used so you get different statistics depending on the PC you are on, even when the ini file is stored on the network. That would be better for the history too, but at the time when I created this, Windows 3.1 and later Windows 95 were mostly standalone systems.

[Sir_SiLvA]

The new location under Appdata\local is used so you get different statistics depending on the PC you are on, even when the ini file is stored on the network. That would be better for the history too, but at the time when I created this, Windows 3.1 and later Windows 95 were mostly standalone systems.

Im not sure if that works on 3.x/9x-System but wouldnt it be easier to use Mac-Adress/PC-Name for that?

IMHO a program is NOT portable the moment it saves data in the registry/app-folder of the pc used.

[Galizza]

IMHO a program is NOT portable the moment it saves data in the registry/app-folder of the pc used.

That is the desirable behaviour of a portable program

[Stefan2]

The new location under Appdata\local is used so you get different statistics depending on the PC you are on,

I use TC as portable app.
Please keep mostly all TC related files in the TC folder and do not spread it into different locations.
Especially such sensible data.

Even worst this is enabled on default, and if I wouldn't read this forum I wouldn't notice
that I leave back such data on the PC I used on a location I didn't know about as I think I use TC as portable.

And I want to make a backup by just copying my TC folder and use it e.g. on an Test-PC.
But since I doesn't copy that tcDirFrq.txt too, I can't use this feature on my Test-PC.

What if I have TC on an USB-Stick and use that on an customer PC?
I would leave back the tcDirFrq.txt?


Maybe use the hostname in the file name if you want to keep different statistics for different PCs.
Like "tcDirFrq_TestPC01.txt", but please keep it beneath of the TC-folder.


Only use AppData if the TC-folder is write protected.


 

[Dalai]

I think a user creating a portable TC can be tasked with making the necessary adjustments to wincmd.ini - which must be made anyway for things like UseIniInProgramDir and probably others. And in such cases, DirUsageLocation should be set to some write-protected location.

As I already said in the other thread: Don't assume that the TC directory is writable, because most of the time it's not (unless you're an administrator)!

[EDIT]

And I want to make a backup by just copying my TC folder and use it e.g. on an Test-PC.
But since I doesn't copy that tcDirFrq.txt too, I can't use this feature on my Test-PC.

Yes, you can. Set DirUsageLocation to %COMMANDER_PATH% and you'll copy this file along with the TC directory.

What if I have TC on an USB-Stick and use that on an customer PC?
I would leave back the tcDirFrq.txt?

Set DirUsageLocation to %COMMANDER_PATH% or a read-only or non-existent location (e.g. C:\nul) in such cases to avoid leaving this file behind. But it's not that this file contains any secrects related to your TC. It's this particular PC's directories after all.

[/EDIT]

Regards
Dalai

[Stefan2]

. . .making the necessary adjustments to wincmd.ini . . .

Me think, one single ""UseIniInProgramDir=7"" should make it all.

AND he must know about what's needed at first place.




 

[Dalai]

Me think, one single ""UseIniInProgramDir=7"" should make it all.

It's not that just this setting alone is going to make TC portable. There's much more to consider, like paths to plugins, the button bar buttons, paths in internal associations, ThumbsLocation[1], TreeFileLocation[1], DriveLib, IconLib and probably many more. They likely need to be adjusted to make TC fully portable.

[1] These are located in %LocalAppData% by default by the way, same as DirUsageLocation.

AND he must know about what's needed at first place.

True. It's enough noise about this feature now, isn't it?

Regards
Dalai

[Horst.Epp]

To repeat and support what Dalai said
It's enough noise about this feature now.

It looks like just because one user sees no usage of this new feature
we discuss funny things around it.

Btw. I like it

[Usher]

It's this particular PC's directories after all.

Wrong. There are all directories saves there - including paths from the portable drive, from network drives and from plugins used by this TC instance.