misha.cn.ua
8th March 2004 12:02 UTC

A BIG problem during installation
I created an installation with NSIS 2.0, and founded, that it works as follows:
1. Create a zero size file in the destination directory.
2. Decompress file to %TEMP%.
3. Copy (!) file from %TEMP% to file, created at step 1.
4. Delete file in %TEMP%
5. Jump to step 1 with next file.

And now, imagine, I have 600Mb free on my drive C, and installing a single 500Mb file on it... The installer will allow to start installation, because there is enough free space, but then will give an error... and after this you say that NSIS does not suck...

PS: I am using Windows 2000 SP3.

Joost Verburg
8th March 2004 12:23 UTC

That is the decompression cache for solid installers.

See http://nsis.sourceforge.net/download/special_builds/ if you don't want to use solid compression.

Joost Verburg
8th March 2004 12:23 UTC

That is the decompression cache for solid installers.

See http://nsis.sourceforge.net/download/special_builds/ if you don't want to use solid compression.

misha.cn.ua
8th March 2004 12:54 UTC

Thanks.

But why not to decompress file directly to destination?
Why do you use temp? And why do you copy file, moving would be much faster.

Joost Verburg
8th March 2004 15:34 UTC

It stores the decompressed data in one temp file, otherwise it would have to decompress everything again once something should be retrieved from another location.

misha.cn.ua
10th March 2004 06:31 UTC

Ok, but how than such archivers, as WinRAR, 7-zip and others unpack solid archives?

Joost Verburg
10th March 2004 14:03 UTC

They have no installer feature and only have to decompress things in one specific order.

misha.cn.ua
11th March 2004 11:40 UTC

But NSIS also decompress in one specific order. And if it needs to skip some files, it must do the same thing as WinRAR does when you want to decompress only one file from solid archive.
I can't understand you. Why file must be decompressed to %TEMP%? Why not to use destination file as "cache"???

eccles
11th March 2004 13:50 UTC

But NSIS also decompress in one specific order

misha.cn.ua
11th March 2004 14:35 UTC

Thanks for explanation.

Than I think, the option to make non-solid installations *must* be in the main distribution of a NSIS. The compressors list must be something like "zlib, zlib solid, bzip2, bzip2 solid, lzma, lzma solid".

misha.cn.ua
14th March 2004 07:51 UTC

Please, tell me, if non-solid compression will be included in main NSIS distribution? Not everyone needs non-solid compression, but also not everyone wants solid compression.

Joost Verburg
14th March 2004 11:44 UTC

You can download a build with non-solid compression from the website.

Of course a compiler setting would be a nice feature, it's already on the feature request list. However, there are many features people request so it might take some time before something like this will be added.

misha.cn.ua
15th March 2004 13:30 UTC

Thanks.

lroathe
4th June 2004 22:13 UTC

This is a hidden problem of larger magnitude
All,

I've finally tracked down problems reported to me about bad installations to this very issue; I used LZMA for my compression (solid, from 2.0) and while my installations are very small (100MB, 180MB uncompressed) people often run out of HD space and the installer crashes.

I don't have the time to test for more info or put in a small HD and will just use the special build for LZMA non-solid for now, but this needs to be looked at further as it is an issue that negatively effects an otherwise solid install experience.

lroathe
5th June 2004 17:25 UTC

Follow up: I took one of my largest projects, which is 180MB on disk with 5,654 files in 500 folders. Using solid lzma compression the resulting installer is 100MB in size. Using non-solid compression, the resulting installer is 102MB in size.

As this project probably represents about the best case real-world example for solid compression yet only saves 2MB, I'd suggest that non-solid compression for lzma (not sure about bz2) be the default. I'd bet that at least 90% of the people creating installers would agree that a small increase in size is worth avoiding the problems the very large temporary file creates for customers... esp. when the customer runs out of disk space during the install; which can lead to a non-working hard drive and very (very) upset customers; I spent 3 hours on long distance with one walking him through recovering his HD after this happened.

Actually; the installer _really_ should check for enough free HD space before attempting to install. And if a temp file will be created, the max size of that temp file should be taken into account. (ie, install size = 200MB, temp file == 180MB, total free HD required == at least 380MB).