Real Life Story: "File expected from server..." error

[NewsArchive]

The new SetupBuilder 6.5 install images for build 1953 where ready. 600
hours of hard work, numerous important bug fixes and enhancements.

We uploaded the full and trial install images for both Developer and
Professional editions, then the web update cluster files to automatically
handle live updates.

Our favorite FTP tools to upload files to our web server are "FTP Voyager"
and "FTP Explorer". No errors where reported during the FTP upload process.
Perfect, here we go. The server was ready to power thousands of live
update requests for SetupBuilder.

But before we make the updated software and web pages available, we always
perform a final test. We download and install all setup images from our web
server. Then we install previous versions and verify that the web update
process works as expected.

Developer Edition live-updated without any problem. It updated the Gold
(version 6.0) and the last official release (that is version 6.5 build 1911)
to the brand new build 1953.

Then we performed the web update for Professional Edition. Suddenly, web
update reported the following error:

"File expected from server and received file do not match: <filename>. This
is a critical error and Setup will terminate. Please contact the author of
this installation file."

Then the installer rolled back all modifications.

This isn't something you want to see a few seconds before a new version of
your software goes live! What the hell... Was this a showstopper in our
new and extensively tested update?

To make a long story short, it was not a showstopper. SetupBuilder was
smart enough to detect a transmission error and prevented the system from
installing a corrupted file. What happened? During the FTP upload process
a cluster file got corrupted and the FTP software did not detect this
transmission failure.

I uploaded the file again and this solved the problem!

We'll develop a new "Server Cluster File Integrity Test" feature so you can
check from the SetupBuilder IDE if there was any kind of upload transmission
problem.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> To make a long story short, it was not a showstopper. SetupBuilder was
> smart enough to detect a transmission error and prevented the system from
> installing a corrupted file. What happened? During the FTP upload process
> a cluster file got corrupted and the FTP software did not detect this
> transmission failure.
>
> I uploaded the file again and this solved the problem!
>
> We'll develop a new "Server Cluster File Integrity Test" feature so you can
> check from the SetupBuilder IDE if there was any kind of upload transmission
> problem.

Nice save - SetupBuilder to the rescue as always!

I'm not sure if your doing this now, but if your going to be in that part
of the code, how about having it so that when you use the built-in FTP that
it follows a sequence like this:

1) upload the new file as "filename.up" (or whatever alternate extension)
2) check the upload to see if it is the right size
3) rename the current file with a .last extension (or something)
4) rename the .up file to the true filename

This would do few good things:

1) For developers on a slow connection with a BIG upload - it would not
take the current download out of play

2) If the connection failed - the current download would not be broken or
corrupted.

3) In the event that a developer has one of those moments like you just
had, they could easily take an FTP program and delete the new file that
people were downloading - and rename the last good version into place.


This is especially important for downloads where there is a demo version
since an end user who has a bad experience with a download may simply find
another product.

We always save the previous good version of our downloads on the server
(and have not been using the built-in FTP because of this).

Anyway that is my idea for the day<g>


Charles





--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

Hi Charles,

>
> Nice save - SetupBuilder to the rescue as always!
>

;-)

> I'm not sure if your doing this now, but if your going to be in that part
> of the code, how about having it so that when you use the built-in FTP
> that
> it follows a sequence like this:
>
> 1) upload the new file as "filename.up" (or whatever alternate extension)
> 2) check the upload to see if it is the right size
> 3) rename the current file with a .last extension (or something)
> 4) rename the .up file to the true filename
>
> This would do few good things:
>
> 1) For developers on a slow connection with a BIG upload - it would not
> take the current download out of play
>
> 2) If the connection failed - the current download would not be broken or
> corrupted.
>
> 3) In the event that a developer has one of those moments like you just
> had, they could easily take an FTP program and delete the new file that
> people were downloading - and rename the last good version into place.
>
>
> This is especially important for downloads where there is a demo version
> since an end user who has a bad experience with a download may simply find
> another product.
>
> We always save the previous good version of our downloads on the server
> (and have not been using the built-in FTP because of this).
>
> Anyway that is my idea for the day<g>

What *I* do is, I change the web update name for each and every new web
update release.

For example, for Build 1911 it was:

sb6_1911_dev.exe
sb6_1911_dev.00001
etc.

For the new Build 1953 it is:

sb6_1953_dev.exe
sb6_1953_dev.00001
etc.

The server manifest file is always named "sb60_dev.ini", so I only have to
temporarily rename the new "sb60_dev.ini" (build 1953) to "sb60_dev_tmp.ini"
before uploading. Then I transmit all the new web update stuff to the
server. The old web update (build 1911) is still active!

Now I test the new web update (build 1953) by installing the previous
version of SetupBuilder. Then I open the registry and change the server
manifest file reference (that is the HOST_INI value under the
WebUpdate\Apps\<GUID> registry key) from "sb60_dev.ini" to
"sb60_dev_tmp.ini". This allows me to test the new (build 1953) web
update - and the old (build 1911) web update still works fine!

Okay, tests where successful. To make the new web update available to the
public, I only have to remove "sb60_dev.ini" (build 1911) from the server
and rename "sb60_dev_tmp.ini" to "sb60_dev.ini". This takes < 1 second. So
web update checking is only unavailable during this "rename" process (<1
sec). And all users still busy with a web update for the previous version
can continue doing this. No interruption, no corruption, nothing.

I am sure the above process can be completely automated (this would be a
very cool addition).

Friedrich

[NewsArchive]

> What *I* do is, I change the web update name for each and every new web
> update release.

That would work fine for the Web Update (thanks for the tip<g>).

What I was thinking of was the main download file.

For example: SetupFotoKiss.exe

When this EXE is linked into hundreds of download sites, you can't change
the exe name because it would take you a week to go back to each of the
sites and some would be broken all the time until you were done.

Maybe for the main exe it could go like this:

For example Build 1911

The file gets uploaded as SetupFotoKiss.1911

Then that file (once verified on the server) gets RENAMED on the server as
SetupFotoKiss.exe

Then when the next build 1912 is FTP'd by SetupBuilder it goes up as
SetupFotoKiss.1912

Then SetupFotoKiss.exe gets renamed as SetupFotoKiss.1911 and the
SetupFotoKiss.1912 gets renamed as SetupFotoKiss.exe


That should be fairly easy to do and in fact it would allow multiple
versions to be kept on the server so that one could quickly rollback more
than one if needed.


I'd suggest a field in SB to determine how many revisions to keep in the
server (after that - then the oldest is deleted after a new one comes up)


I think that this could be automated (along with your idea for the same on
the update files).


Last but not least (since your rounding off the new "feature"<g>) maybe a
"FTP Version Manager" visualizer tab in SB that would show the names of the
version sets that were on the server, plus indicate which was the "active"
version.

Then have an option for the developer to be able to pick any of the sets
and click a button to have SB access the server and rename the file sets.

This would be VERY cool as it would eliminate the developer from having to
use a external FTP program and do it manually.

Less chance to make a mistake that way and once again SB is the hero<g>.

;-)

Charles



--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

www.clarionproseries.com - "Serious imaging tools for Clarion Developers"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms!"
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

This is more or less what I do now Charles.

I have SB ftp the file as SetUpApp.exe. Then once verified as OK (I download
and install from the site) I then rename the file on the server.

So if SB could in any way ftp and rename the file (optionally) that would be
so cool.

John Fligg

[NewsArchive]

Hi Friedrich,

>For example, for Build 1911 it was:
>
>sb6_1911_dev.exe
>sb6_1911_dev.00001
>etc.

Thanks for that tip!

Best regards,

Arnór Baldvinsson
Icetips Creative, Inc.
San Antonio, Texas, USA
www.icetips.com


Subscribe to information from Icetips.com:
http://www.icetips.com/subscribe.php