Re-install Fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install on Windows 7
2. Uninstall
3. Re-install

What is the expected output? What do you see instead?

Installer gets to kaddemostatic.exe and seems to fail. It makes the error
sound and doesn't go any further. No messages on the screen or in the event
log. Just have to hit cancel to abort the install. The directory only ends
up with Chkupdate.bat and update.ini.

Pretty sure the install worked the first time, but it didn't run it because
I hadn't installed maidsafe-dht yet.

What version of the product are you using? On what operating system?

0.1.0 and Windows 7

Please provide any additional information below.

After the initial install and uninstall, I installed maidsafe-dht. Am
running the installer as an administrator. Can't think of any reason why it
would fail.

Original issue reported on code.google.com by xtopher....@gmail.com on 26 Apr 2010 at 8:02

[GoogleCodeExporter]

Hi, thanks for the interest.  I suspect the uninstaller is neglecting to clean
something up, I'll take a look just now though and get back to you.

Cheers,
Alec

Original comment by alecangus@gmail.com on 27 Apr 2010 at 9:40

[GoogleCodeExporter]

I got a similar problem when installing on Windows XP. The installer got frozen 
in a
step (around 80% of the process) and I had to cancel if after a lot of minutes.

I tried to install it 5 times and got the same problem.

In my case the installation never worked.

Original comment by bakt...@gmail.com on 27 Apr 2010 at 11:48

[GoogleCodeExporter]

Hi,

The issue was that at a certain point in the install, we schedule a task using
schtasks, which hung the installer while it waited for user input but as the
installer was driving it there was no opportunity for the user to give the 
input.

Before running the updated installer (available from the Downloads page), you 
may
have to clean up the scheduled task from the old one.  It's called "Perpetual 
Data
AutoUpdate" and can be removed by right clicking on it in Control Panel > 
Scheduled
Tasks.

Many thanks,
Alec

Original comment by alecangus@gmail.com on 27 Apr 2010 at 4:23

• Changed state: Fixed

[GoogleCodeExporter]

i strongly recommend a review of this bug, as this is an internationalization 
problem.

i tested the kaddemo 0.1.0 installer some weeks back but didnt have time to 
report
back the loads of problems i had already with the basic installer.

just tried to install the maidsafe-dht-0.1.0-windowsinstaller package, and it 
has a
pretty similar problem during basic first install (clean winxp machine in terms 
of
maidsafe-dht projectwise, so no previous attempts to install/uninstall your 
installers)

having a (some language restrictionas apply, some languages come with localized 
aka
translated parameters for schtasks some dont, crazy msft folks :( ) non-english
version of for example winxp/32bit (professional, sp3 applied) (for example 
german
winxp professional) features localized commandline-parameters of the 
schtasks.exe
command. it wont take the "hourly" parameter where it has been 
localized/translated.

http://msdn.microsoft.com/en-us/library/bb736357.aspx

maybe msft allows for redistribution of their schtask.exe app in a generic way, 
or
with standard single-language parameters or offers other means (api) to 
generated
planned tasks.

regards.

Original comment by abitt...@gmail.com on 4 May 2010 at 1:41

[GoogleCodeExporter]

ah yes, now i remember, i recreated the kaddemo 0.1.0 installer situation at my
place, on a winxp32bitsp3english machine where the bitrock installer (seems 
quite a
huge monolithic bloatware to me if i may add my humble opinion here, its way 
too huge
for what it does)

the kaddemo 0.1.0 installer calls:
schtasks.exe /create /sc hourly /tn "Perpetual Data AutoUpdate" /tr "C:\Program
Files\kaddemo-0.1.0\chkupdate.bat"

which results in eternal hanging when the current user on winxp actually has 
set a
password for its account.

trying the command directly on the commandline:
C:\>C:\WINDOWS\system32\schtasks.exe /create /sc hourly /tn "Perpetual Data
AutoUpdate" /tr "C:\Program Files\kaddemo-0.1.0\chkupdate.bat"

displays that the schtasks command will wait for the user entering its current 
password:

The task will be created under current logged-on user name 
("MACHINE\username1010").
Please enter the run as password for MACHINE\user1010: ^C

---------------

the maidsafe-dht 0.1.0 installer apparently learned from this previous mistake 
and
specifies the SYSTEM account as it can be seen with tools like processexplorer 
and
similar ones:

schtasks /create /sc HOURLY /tn "MaidsafeDHT AutoUpdate" /tr "c:\Program
me\maidsafedht-0.1.0\chkupdate.bat" /ru "SYSTEM"

the only problem with this one is like i wrote above, that it doesnt work 
because of
the "hourly" parameter on for example german and italian localised windowsxp
installations.

regards.

Original comment by abitt...@gmail.com on 4 May 2010 at 2:05

[GoogleCodeExporter]

Sorry about this, it's an oversight on my part.  I'll fix the HOURLY argument 
and
review the rest of the installer to ensure it's internationally compliant.

Thanks for the feedback, I'll post back once it's updated.

Original comment by alecangus@gmail.com on 4 May 2010 at 3:10

• Changed state: Started

[GoogleCodeExporter]

Manually calling schtasks was a workaround for not being able to correctly use
Bitrock's own option to schedule a task, so I've taken the opportunity to 
revisit
that and find out how it should be done used.  I've emailed Bitrock to ask how 
it was
intended to be used and am waiting to hear back.

Original comment by alecangus@gmail.com on 6 May 2010 at 1:07

[GoogleCodeExporter]

I've heard back from Bitrock saying they've tracked down the issue with their
software and will send me out a new build with the fix this week.

At that point I can fix our installer and we'll all be happy :)

Original comment by alecangus@gmail.com on 10 May 2010 at 9:26

[GoogleCodeExporter]

Bitrock have come back to me with a fix for this problem, but say that through 
this
they've identified a problem with the same thing in Windows 7 that still wont 
work. 
They're going to come back to me with a workaround for Windows 7 for now.

Original comment by alecangus@gmail.com on 27 May 2010 at 1:21

[GoogleCodeExporter]

Closing items to make way for new library.

Original comment by irvine.d...@gmail.com on 14 Jan 2011 at 11:30

[GoogleCodeExporter]

Original comment by irvine.d...@gmail.com on 14 Jan 2011 at 11:30

• Changed state: WontFix