2 replies to this topic

[clvrmnky]

Greetings,

I've run into a problem where my guard code that checks for cases where the MEDIA is bigger than the TARGETDIR device is firing for no good reason (that I can see).

I'm using ComponentCompareSizeRequired() to check MEDIA after calling SdSetupTypeEx() and/or SdComponentTree(). TARGETDIR has been set by a previous call to SdAskDestPath().

The problem is that we've run into a test case where TARGETDIR points to (say) D: (which is not the boot device) with plenty of space, but my guard code still fails the install because of a lack of space on C:.

I do have the MFC object included in the install, but it will not be installed, as this box has had the same install run on it several times.

I've changed the message I report on failure of ComponentCompareSizeRequired() to see what device it is complaining about, as well as how many bytes are required, but I'm certain that it is lack of space on the boot device that is causing this. Shouldn't space required for SUPPORTDIR be checked on startup? If it isn't the population of SUPPORTDIR causing the problem, is the MFC object being counted, even though it will not be installed (I suspect this is something checked later, based on DLL versions and such)?

Any ideas or suggestions welcome.

-- cm

[Taco Bell]

Yes, space on C: is still an issue as shared common files and system files are stored there. Not to mention the supporting uninstall information and InstallShield use's of the temporary directory for decompressing the CAB files.

Not sure about how Objects fall into play though as I don't use them.

[clvrmnky]

Thanks for the sanity check. I'm pretty sure this must be it, as well. All the stuff that IS needs to do in C: will require space, some of which cannot be determined until runtime.

I just got our docs team to mention this in the release notes.