Copying Take Command installed folder

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
May 30, 2008
122
1
#1
I want to take a backup of my Take Command installation (program
folder, 4START, aliases files, plugins, etc). Without wanting to start
a flamewar, I keep all my files (ini file, etc) in the program
directory - I am not on Vista and this approach works fine for me.

If I simply copy my program folder, and later (say, when I have a
problem and have to reinstall the OS) copy it back and run tcmd.exe
from there, will things work as expected? I know I'll need to
reregister the program, and I'll lose window position settings and the
like, but will such things as auto-update work?

Thanks,
Paul.
 

rconn

Administrator
Staff member
May 14, 2008
10,097
85
#2
p.f.moore wrote:

> I want to take a backup of my Take Command installation (program
> folder, 4START, aliases files, plugins, etc). Without wanting to start
> a flamewar, I keep all my files (ini file, etc) in the program
> directory - I am not on Vista and this approach works fine for me.
>
> If I simply copy my program folder, and later (say, when I have a
> problem and have to reinstall the OS) copy it back and run tcmd.exe
> from there, will things work as expected? I know I'll need to
> reregister the program, and I'll lose window position settings and the
> like, but will such things as auto-update work?
Yes, barring things like the batch file associations, Explorer context
menu entries, window state/order/size/position, theme, skin, and any
shortcut keys. The autoupdate will still work as long as the .aiu file
is still there.

Rex Conn
JP Software
 
May 30, 2008
122
1
#3
2008/7/5 rconn <>:

> Yes, barring things like the batch file associations, Explorer context
> menu entries, window state/order/size/position, theme, skin, and any
> shortcut keys. The autoupdate will still work as long as the .aiu file
> is still there.
But presumably if I need to do an OS wipe & reinstall, the .aiu file
gets lost. Is there any way of recovering autoupdate in that situation
other than reinstalling?

Paul.
 

rconn

Administrator
Staff member
May 14, 2008
10,097
85
#4
p.f.moore wrote:

> 2008/7/5 rconn <>:
>
> Quote:
> > Yes, barring things like the batch file associations, Explorer context
> > menu entries, window state/order/size/position, theme, skin, and any
> > shortcut keys. The autoupdate will still work as long as the .aiu file
> > is still there.
>
> But presumably if I need to do an OS wipe & reinstall, the .aiu file
> gets lost. Is there any way of recovering autoupdate in that situation
> other than reinstalling?
Why would it be lost? You said you were backing up the installation
directory, which includes the .aiu file.

Rex Conn
JP Software
 
May 30, 2008
122
1
#5
2008/7/5 rconn <>:

> Why would it be lost? You said you were backing up the installation
> directory, which includes the .aiu file.
Am I missing something? My TCMD9 installation directory doesn't
include a .aiu file. I thought it went somewhere in the bowels of the
"Application Data" tree...


>dir \Apps\TCMD9 /a:
Volume in drive C is Windows Serial number is b087:e240
Directory of C:\Apps\TCMD9\*

05/07/2008 16:16 <DIR> .
05/07/2008 16:16 <DIR> ..
05/07/2008 16:16 <DIR> Styles
01/06/2008 08:41 79,160 4nt.exe
18/01/2008 11:24 9,461 BATCH.BCP
01/06/2008 08:41 215,352 Bchild.dll
01/06/2008 08:41 454,968 English.dll
19/02/2008 23:36 20,342 examples.btm
01/06/2008 08:41 570,680 French.dll
09/03/2008 20:42 0 FTP.CFG
01/06/2008 08:41 569,144 German.dll
10/04/2008 13:04 652,752 ipworks6.dll
10/04/2008 13:38 579,024 ipwssl6.dll
14/04/2008 21:41 9,446 license.txt
01/06/2008 08:41 312,632 onig.dll
03/05/2008 23:26 6,295 readme.txt
01/06/2008 08:41 14,136 ShrAlias.exe
01/06/2008 08:41 832,312 TakeCmd.dll
01/06/2008 08:41 79,160 tcc.exe
03/05/2008 13:21 984 tccbatch.btm
03/05/2008 13:29 1,154 tcchere.btm
29/05/2008 09:06 1,589,774 tcmd.chm
01/06/2008 08:41 2,795,320 tcmd.exe
04/07/2008 23:03 339 TCMD.gpf
05/07/2008 20:15 2,731 TCMD.INI
03/05/2008 13:29 1,188 tcmdhere.btm
15/02/2008 23:22 622 TCSTART.BTM
01/06/2008 08:41 287,032 updater.exe
05/07/2008 16:16 312 updater.ini
01/06/2008 08:41 230,712 WiFiMan.dll
9,315,032 bytes in 27 files and 3 dirs 9,383,936 bytes allocated

Looking at updater.ini, the .aiu file is in C:\Documents and
Settings\Gustav\Application Data\JP Software\Take Command
9.02\updates\, which would be trashed by a reinstall.

Paul.
 
#6
On Sat, 05 Jul 2008 18:05:34 -0500, you wrote:


>Am I missing something? My TCMD9 installation directory doesn't
>include a .aiu file. I thought it went somewhere in the bowels of the
>"Application Data" tree...
Here, it's in the profiles tree.

...\Application Data\JP Software\<product>\updates\tcmdupdate.aiu
 
May 30, 2008
122
1
#7
2008/7/6 vefatica <>:

>>Am I missing something? My TCMD9 installation directory doesn't
>>include a .aiu file. I thought it went somewhere in the bowels of the
>>"Application Data" tree...

> Here, it's in the profiles tree.
>
> ...\Application Data\JP Software\<product>\updates\tcmdupdate.aiu
Exactly. So if I don't back that up (and hence, it gets lost) will
autoupdate still work, or do I need to do a full reinstall?

Paul.
 
#8
p.f.moore wrote:
| ---Quote---
|| Here, it's in the profiles tree.
||
|| ...\Application Data\JP Software\<product>\updates\tcmdupdate.aiu
| ---End Quote---
| Exactly. So if I don't back that up (and hence, it gets lost) will
| autoupdate still work, or do I need to do a full reinstall?

If you don't back up the profiles tree, all installation information of all
installed programs is lost, including most or all internet connection data
(Firefox preferences and passwords, Thunderbird and Outlook Express
identities, etc. Of course the same is true for the registry.
--
Steve
 
May 30, 2008
122
1
#9
2008/7/6 Steve Fábián <>:

> If you don't back up the profiles tree, all installation information of all
> installed programs is lost, including most or all internet connection data
> (Firefox preferences and passwords, Thunderbird and Outlook Express
> identities, etc. Of course the same is true for the registry.
By adhering to a policy of avoiding as much as possible programs which
store configuration information and user preferences in the registry
and profiles tree, I minimise the amount of reinstallation and
reconfiguration I have to do on an OS installation. Microsoft doesn't
agree with this policy, but I don't agree with some of the things they
do, either :-)

I like to wipe and reinstall my OS fairly frequently. The worst part
of this is not the OS install, nor the recovery of my data - it's
reconfiguring all the applications that I have to reinstall from
scratch. Applications which can be backed up and restored like data
make this process far easier.

My dislike of the profiles tree is that it is as much an unstructured,
opaque blob of data as the registry ever was. Worse still, it's big
(it includes "My Documents", and hence "My Pictures" and "My Videos")
and large chunks of it which I am expected to care about are hidden
(for example, the appdata bit, as we are discussing here). I would
never organise my data like this, and I resent being forced to do so
by the OS.

Ultimately, however, why I want to do this (and whether it's a good
idea or not) is irrelevant. My question is simply if autoupdate will
break if the .aui file is lost (and another thread here, where someone
reported that it had got corrupted and he removed it and things
started working again, seems to establish that it won't break).

Paul.
 

rconn

Administrator
Staff member
May 14, 2008
10,097
85
#10
p.f.moore wrote:


> Ultimately, however, why I want to do this (and whether it's a good
> idea or not) is irrelevant. My question is simply if autoupdate will
> break if the .aui file is lost (and another thread here, where someone
> reported that it had got corrupted and he removed it and things
> started working again, seems to establish that it won't break).
Take Command rebuilds tcmdupdate.aiu if it's missing.

Rex Conn
JP Software
 
Jun 7, 2008
96
3
#11
2008/7/6 Steve Fábián <>:


> If you don't back up the profiles tree, all installation information of all
> installed programs is lost, including most or all internet connection data
> (Firefox preferences and passwords, Thunderbird and Outlook Express
> identities, etc. Of course the same is true for the registry.
Note that Mozilla programs can be told *where* to put the profile
data, when you create a profile in Profile Manager.

I have multiple Mozilla based products installed, with multiple
profiles for some of them, customized for different purposes. To make
maintenance simpler. I created a \Mozilla directory, with folders
beneath if to bookmarks, extensions, themes, install packages, and
profiles. New profile instances get created under
\Mozilla\Profiles\<product>\<version>\<profile name>

It makes keeping track and maintenance much simpler.


______
Dennis
 
Jun 7, 2008
96
3
#12
On Sun, Jul 6, 2008 at 12:00 PM, p.f.moore <> wrote:


> My dislike of the profiles tree is that it is as much an unstructured,
> opaque blob of data as the registry ever was. Worse still, it's big
> (it includes "My Documents", and hence "My Pictures" and "My Videos")
> and large chunks of it which I am expected to care about are hidden
> (for example, the appdata bit, as we are discussing here). I would
> never organise my data like this, and I resent being forced to do so
> by the OS.
You aren't, entirely. For instance, right-click on teh My Documents
icon on your desktop, and select Properties. You can specify the
location of the My Documents folder, and don't *have* to place it in
the profiles tree.

Agreed in general, however. Back in the MS-DOS days, I went through
some effort to use a Unix like filesystem layout. that's not quite
possible under Windows.


______
Dennis
 
#13
p.f.moore wrote:
| By adhering to a policy of avoiding as much as possible programs which
| store configuration information and user preferences in the registry
| and profiles tree, I minimise the amount of reinstallation and
| reconfiguration I have to do on an OS installation. Microsoft doesn't
| agree with this policy, but I don't agree with some of the things they
| do, either :-)

I personally hate the registry concept. It becomes too big too quickly, and
requires special tools to remove deadwood. However, I do agree the Vista
concept that directories containing executable programs should not contain
dynamic data. In fact, I would preferrably extend this to physical drives.
In almost every file system I've come across in my nearly 50 years in the IT
world, only one of the Data General file systems had modes in which file
sets could be restricted to a single contiguous part of a drive, somewhat
analogously to partitioning. But neither partitioning nor the DG contiguous
allocation prevent a transient single bit error in the hardware-level disk
address to cause accessing, and possibly overwriting, the incorrect disk
location. That's why data and code ought to be on separate drives.

| I like to wipe and reinstall my OS fairly frequently. The worst part
| of this is not the OS install, nor the recovery of my data - it's
| reconfiguring all the applications that I have to reinstall from
| scratch. Applications which can be backed up and restored like data
| make this process far easier.

... and this is true even if the configuration control files reside
separately from the program files, as long as they can be easily located to
be backed up.

| My dislike of the profiles tree is that it is as much an unstructured,
| opaque blob of data as the registry ever was. Worse still, it's big
| (it includes "My Documents", and hence "My Pictures" and "My Videos")
| and large chunks of it which I am expected to care about are hidden
| (for example, the appdata bit, as we are discussing here). I would
| never organise my data like this, and I resent being forced to do so
| by the OS.

You can easily unhide everything using TCC (or 4nt, or even TCCLE). Others
posted responses relating to the "My ..." stuff. I never use them myself,
anyway!
--
Steve
 
#14
DMcCunney wrote:
| Note that Mozilla programs can be told *where* to put the profile
| data, when you create a profile in Profile Manager.

Thanks! I didn't know that. Can an existing profile be moved to a new
location?

| I have multiple Mozilla based products installed, with multiple
| profiles for some of them, customized for different purposes. To make
| maintenance simpler. I created a \Mozilla directory, with folders
| beneath if to bookmarks, extensions, themes, install packages, and
| profiles. New profile instances get created under
| \Mozilla\Profiles\<product>\<version>\<profile name>

Is that done so automatically?

| It makes keeping track and maintenance much simpler.

It sure does, esp. when migrating to a new system, or when changing the
drive configuration. It may even allow me to run Firefox on another user's
machine from a USB drive...
--
Steve
 
#16
There's a "portable" version of Firefox already
available at http://portableapps.com/news/2008-06-17_-_firefox_portable_3.0



mr.Jiggs


Steve F&aacute;bi&aacute;n wrote:




DMcCunney wrote:
| Note that Mozilla programs can be told *where* to put the profile
| data, when you create a profile in Profile Manager.

Thanks! I didn't know that. Can an existing profile be moved to a new
location?

| I have multiple Mozilla based products installed, with multiple
| profiles for some of them, customized for different purposes. To make
| maintenance simpler. I created a \Mozilla directory, with folders
| beneath if to bookmarks, extensions, themes, install packages, and
| profiles. New profile instances get created under
| \Mozilla\Profiles\\\

Is that done so automatically?

| It makes keeping track and maintenance much simpler.

It sure does, esp. when migrating to a new system, or when changing the

drive configuration. It may even allow me to run Firefox on another
user's
machine from a USB drive...
--
Steve
 
#17
joshjeppson wrote:
| ---Quote (Originally by Steve Fábián)---
| It may even allow me to run Firefox on another user's machine from a
| USB drive... ---End Quote---
|
| If you want to run Firefox from a USB stick, there are specific
| portable builds of it that you can use.
|
| For example, the very first google result for "portable firefox":
| http://portableapps.com/apps/internet/firefox_portable

Thanks!
--
Steve
 
Jun 7, 2008
96
3
#18
2008/7/6 Steve Fábián <>:

> DMcCunney wrote:
> | Note that Mozilla programs can be told *where* to put the profile
> | data, when you create a profile in Profile Manager.
>
> Thanks! I didn't know that. Can an existing profile be moved to a new
> location?
Probably. First, you need to pick up the profile tree and copy it to
the desired location. Firefox uses a file called profile.ini to
discover where the profile tree for the selected profile lives when
you run it. You'll need to edit that to reflect the new location.
See http://kb.mozillazine.org/Profiles.ini_file for details.

I use shortcuts to run profiles, with Target: lines like "D:\Program
Files\Mozilla.org\Firefox\Firefox.exe -p "Dennis McCunney" to specify
the profile I wish to use.

An alternative method is to invoke Program Manager, and *delete* the
profile you want to move. Profile Manager will ask you if you want to
delete the associated files. Say No. Then create a new profile with
the same name, specifying where you want it to reside. Don't invoke
Firefox after doing so. Exit Profile manager, and copy the contents
of the old profile tree, lock, stock, and barrel over the new profile
tree that was created to migrate files and settings. *Now* run
Firefox using the desired profile. After verifying all is well,
delete the original profile tree.

One annoyance for me with Firefox 3: I have multiple Mozilla based
browsers, with multiple profiles. I wanted them all to use the *same*
bookmarks file. Under FF2 and earlier, that was easy. Mozilla
products use a file called prefs.js in the profile directory to hold
configuration information, and prefs.js includes a pointer to the
bookmarks.html file the browsers uses to store bookmarks. Prefs.js is
created and maintained by the browser, and should not be edited.
Instead, create a file called user.js in the profile directory. The
browser doesn't modify it. But if it exists, it will be read, and
settings specified in it will override what is in prefs.js. A one
line user.js file containing

user_pref("browser.bookmarks.file", "D:\\Mozilla\\Bookmarks\\Dennis
McCunney\\bookmarks.html");

did the trick. I copied it into each profile directory I created, the
browsers read it, and they all used that file. (Problems could result
if more than one browser were active at a time, but I didn't do that.)

FF3 replaces bookmarks.html with a database file called
places.sqilite. There is no preference to let you specify where it
lives. This has been complained about, but the Mozilla devs classify
it as a WONTFIX.

To work around it, I had to drop to the OS level. NTFS 5 supports
hard links ala Unix, so I created links in each profile directory for
FF3 to the desired file. There is also a preference you can set in
about:config to force Firefox to dump the sqlite database to a
bookmarks.html file on shutdown. I turned that on, and FF dumps the
file in the location pointed to by the user.js file, so if I run FF2,
Mozilla Suite, Netscape, or Flock, they will see the current version.
It's one way, alas, but I can live with that.

Hard links can't span file systems, so if I want the places.sqlite
file to live on a different drive, I'd have to create the profiles
there. It's possiblle symbolic links would work, but I can't test it.
True symbolic links aren't supported in NTFS unless you run Vista.
I'm running XP Pro SP3, with *no* plans to "upgrade".

Using sqlite as the file format has all sorts of neat possibilities.
and you can run SQL queries on it. There are several freeware GUI
clients for investigating and tweaking sqlite databases, and one has
even been implemented as a Firefox addon. You can't use it to diddle
the current places file, since that is locked when FF is running, but
you can use it to investigate the other sqlite files FF creates in
addition to the places file.


> | I have multiple Mozilla based products installed, with multiple
> | profiles for some of them, customized for different purposes. To make
> | maintenance simpler. I created a \Mozilla directory, with folders
> | beneath it for bookmarks, extensions, themes, install packages, and
> | profiles. New profile instances get created under
> | \Mozilla\Profiles\<product>\<version>\<profile name>
>
> Is that done so automatically?
No, manually. I run Firefox as "firefox.exe -p" to invoke the Profile
Manager. (Actually, I have a shortcut that does it. The same syntax
works for other Mozilla products - just change the exe name as
appropriate.)

Profile Manager asks for a name for the profile, and in the next field
you can specify where to put it.


> > | It makes keeping track and maintenance much simpler.
>
> It sure does, esp. when migrating to a new system, or when changing the
> drive configuration. It may even allow me to run Firefox on another user's
> machine from a USB drive...
Yes, if you don't mind a major performance hit. There are some
pre-packaged portable Firefox builds you might want to look at.


______
Dennis
 
#19
Thanks for the nice exposition. I have another Firefox 3 question: I
suggested back in FF1 days that the profile support separate "default
download directories" for different URLs. My request was ignored. If they
can store separate form-fill (e.g., username and password) information for
each URL, why not download directories? Can you suggest a method to achieve
this goal?
--
Steve
 
Jun 7, 2008
96
3
#20
2008/7/11 Steve Fábián <>:

> Thanks for the nice exposition. I have another Firefox 3 question: I
> suggested back in FF1 days that the profile support separate "default
> download directories" for different URLs. My request was ignored. If they
> can store separate form-fill (e.g., username and password) information for
> each URL, why not download directories? Can you suggest a method to achieve
> this goal?
Not offhand. What *I'd* like would be different download directories
by content type. (Your suggestion would be useful too, thinking about
it, given what I download. It would be nice if DLs from, say, Project
Gutenberg, always defaulted to the \Ebooks hierarchy on a secondary
drive.)

I'd suggest stopping by the Extensions forum at Mozillazine.com and
inquiring. If such a thing exists, folks there would know about it.
If not, an extension author might get inspired.


______
Dennis