Fixed Dangerous operation when cancelling the installer!

[Ville]

TakeCommand 15.00.19 gave me some heart palpitations today when I cancelled out of its installation. I'm in the process of reinstalling my workstation after hardware upgrade (several days in to setting everything up while having not backed up the system yet ), and while doing so, decided to install beta 15 instead of 14. I started the installer, then remembered I hadn't moved the "JP Software" folder in AppData\Roaming from the old installation so that the configuration would be retained on upgrade, and since the installer creates that folder I decided to cancel the installer before moving the old folder over. I backed out to the first screen of the installer, then hit the [x] in the upper right corner. A message popped up notifying that the installation was not complete. Acknowledged. Then... *poof* my entire Windows user profile folder was gone!!!

What happened? The profile folder wasn't really erased, but because of the way my system is set up, it became disconnected from the c:\Users\MyUserName. Because I use a SSD, and because the profile folder tends to grow quite large in size over time (far exceeding the size of the SSD), I usually house the profile folder on an RAID array while the core system and software installations live on the SSD. I normally move the profile to D:\_LOCAL\MyUserName early on in new system installation and link it to c:\Users\MyUserName. Below is an outline of the process:

1. Make sure a separate admin account is created and accessible (since this is my personal workstation, my own login is an admin user, so the separate admin account is usually the default "Administrator"). Make sure xxcopy (or other similar utility) is installed.
   
2. Restart and start Windows in Safe Mode; log in as the admin
   
3. Open command prompt and copy the existing profile folder to its new location, i.e.
   
   xxcopy c:\Users\MyUserName d:\_LOCAL\MyUserName /H /E /R /Y /YY /KS /TCA /TCC /V1 /ZE /ZY /oNd:\transfer.log /oS3 /oF1 /oE3
   
   The above switches make sure everything gets copied and that the timestamps, etc. are preserved at target. Unfortunately the permissions are not preserved correctly, and they have to be reset (below).
   
4. Compare and match the old and the new folders' privileges (properties > security >advanced); note that the top level owner is the SYSTEM while the profile is otherwise owned by the User whose profile this is (first cascade ownership for the user, then set "SYSTEM" as the owner for the top level only.)
   
5. Rename the old folder:
   ren c:\Users\MyUserName c:\Users\MyUserName.old
   
6. Create a junction point to the new location:
   
   mklink /J c:\Users\MyUserName d:\_LOCAL\MyUserName
   
7. Reboot and test that everything is working, then delete the old user folder at c:\Users\MyUserName.old

I assume that the problem with the installer arises from the fact that the profile folder lives behind a junction point – cancelling the installer deletes the junction point!I've never encountered this problem before (with other software installers), so it must be something specific to TakeCommand. I'm not sure if this something new, specific to beta 15 installer, or whether it has been present with earlier versions as well – maybe I just have never cancelled the installer before.

I was able to restore the profile folder by quickly rebooting the system, logging in as the Administrator in safe mode and re-establishing the deleted junction point to the profile folder location on the array. Then I made a full image backup of the system SSD before repeating the steps to confirm that this is indeed what happened (and it was). Please fix it; this was an unpleasant experience!

 

[rconn]

This would have to be a Windows Installer issue; we're definitely not doing anything with user profiles in the install script.

I'll pass it on to Microsoft (though they've never paid much attention to bug reports in the past).

 

[drwtsn32]

Isn't it more likely to be a bug with "Advanced Installer" and the way it creates MSIs?

I have noticed a few quirks with these installers that I haven't seen with the standard InstallShield ones.

 

[rconn]

Isn't it more likely to be a bug with "Advanced Installer" and the way it creates MSIs?

Unlikely, though I did send a query to the AI developers as well. But that would require something in the MSI scripting language that supported removing junctions, and AFAIK there isn't anything like that.

 

[Ville]

It turns out the problem is more serious! After backing up the system device (SSD) I went ahead and completed the installation of TakeCommand beta 15. When I exited the installer after successful installation the profile folder junction point was deleted again!! Apparently whenever the installer is exited, either through completion of successful installation or through cancellation, the junction point is deleted. What is interesting is that the installation location is not behind that junction point (I'm installing to the standard location at c:\Program Files\JPSoft\TCMD15x64). The installer bug targets the junction point behind which the installing user's profile is at (and where the AppData folders are located). Now I'm positive that this is something new to beta 15 since I previously had the latest build of version TC 14 installed in the exactly same configuration without any problems. This installer problem makes it challenging to use the version 15 unless this is fixed; every time I install a new build, I'll have to reboot the system, log in as Administrator in the safe mode, and recreate the junction point! It's probably a good idea to fix this before the final release as this could affect other situations as well (certainly any situation where the profile folder is linked to on other media).

 

[rconn]

I got a response & workaround from the installer developers this morning, and I have incorporated it into build 20 (already uploaded).

 

[Ville]

It does not seem that the problem has been remedied in build 20. I expected the link to the profile folder to disappear when the previous build (19) was being uninstalled (since that installer had the issue). It did, and I rebooted, logged in as the Administrator, and created the link, rebooted again, logged in as myself, confirmed that TakeCommand was gone, and ran the installer for build 20. The installer completed, I exited it... and watched the profile folder link disappear from c:\Users :( (and then repeated reboot, login as admin, recreate profile folder link, reboot, and log back in as myself). Finally, confirmed that build 20 was indeed installed (it was).

 

[Ville]

Any progress on this? I just upgraded to build 22 and it still behaves the same way (not that anyone claimed it wouldn't :)). As I mentioned in my original post, I've been reinstalling/rebuilding my workstation for the past week and half, and have in that process installed over 250 programs, utilities, etc. This one is the only one that behaves this way (or that I have ever seen an installer behave, and I have installed a lot of programs over the years), so it must be something fairly unique to the new installer TakeCommand 15 uses. My guess is that if it were a Microsoft installer issue, it would be more prevalent and I would've seen it at least with some other programs.

 

[rconn]

It only happens with an .EXE bootstrapper, not with an .MSI file. It happens with the older installers too (at least for v14).

I told the installer developers that their suggested workaround didn't work for you. They haven't responded with any further suggestions or fixes.

 

[Ville]

Are the .msi versions available for download somewhere (also for the beta builds)? I don't mind testing when a proposed fix is available, but meanwhile upgrading to the latest build is a bit of a pain since I have to log out and recreate the profile link after every upgrade.

I never saw this issue with v14, and I've always downloaded the standard installer (exe) from the download page. Suppose something could e different in this new installation, but as far as I know it's set up in exactly the same way as the old setup that I've used at least since 2009.

 

[rconn]

There aren't separate .MSI installers, because I would have to build, test, and upload 12 of them. The .EXE bootstrapper allows me to build a single .EXE with all of the supported languages.

Where is your temp directory? Is that a junction? (That would be very bad.)

 

[Ville]

Ok. Let's hope they'll come up with a solution to fix the problem.

The temp is at d:\_LOCAL\temp .. so it's not behind a junction.

 

[Ville]

Would you mind elaborating why having the temp dir at a junction point is a bad idea? Mine is not, but I'm curious. Thanks!

 

[Steve Fabian]

Historic remark: For many years if the installation directory was a junction (i.e., I attempted to install into f:\jpsoft\beta, a junction to f:\jpsoft\iNN, where NN was 10, or 11, etc. - the version of the beta), the installer would disconnect the junction, and create a real directory beta). I had done that so the same directory name could be used regardless of version for the beta. I have given up years ago, did not even try since V13 was in beta (maybe even before...).

 

[rconn]

I got a response from the installer developers. They're still working on a solution, in the meantime they said:

"The only solution for your users that encounter this problem is to extract (setup.exe "/extract") the resources from the EXE and run the MSI manually."

 

[vefatica]

I got a response from the installer developers. They're still working on a solution, in the meantime they said:

"The only solution for your users that encounter this problem is to extract (setup.exe "/extract") the resources from the EXE and run the MSI manually."

How do you get from a downloaded TCMD.EXE to SETUP.EXE or will TCMD.EXE "/extract" work?

 

[rconn]

setup.exe = tcmd.exe

I was quoting, not rewriting, the developer's response.

 

[Ville]

That will work, thanks for that info! Other alternative is to log out as my account (whose profile is behind a junction) and log in as the Administrator (whose profile is in the standard path) and run the TakeCommand installer from there. That way there is no unnerving disappearance of the profile folder at installer exit.

But I'll use the /extract method until this issue has been fixed.

 

[Ville]

The /extract method does not work: running the resulting msi installer also destroys the junction point to the profile folder.

Earlier today I was installing some other utility (though I now forget which one it was), and it appeared to utilize the same installer (it had the same "Advanced Installer" text in the upper right corner of the install screen, and the install steps appeared similar to that of TC). However, it did not destroy the profile junction point, so perhaps it's not something inherent to the installer, but something specific to TC. Or, perhaps, TC utilizes some features of that installer that trigger the junction point deletion while the other utility does not.