tags:

views:

24

answers:

1

The product I worked on used to utilize an installer other than NSIS. Currently there are still some clients that have a version of a product that was prior to our using NSIS.

Now they are trying to install a new version of our software that uses the NSIS installer. The problem is, when trying to install over any version that was pre-NSIS installer, certain files are not being extracted, which is causing our product to crash.

I have tried to look up and understand how NSIS does its checking for 'ifnewer' but nothing seems to explain it in detail that I can fix the issue.

It should be noted that going from one NSIS installed version to another works fine. So this is a direct result of trying to install over a version of our product that was not installed using NSIS.

Thanks

+1  A: 

Could there be a last modified date issue with the old installer? (In the future etc)

w0lo
I just installed using an old installer again. The last modified date and time was the same as install time. Used new NSIS installer, last modified stayed the same and the only thing to change was the last accessed time. This is why I was wondering how NSIS handles its check for ifnewer, if it goes by last modified there shouldn't be an issue.
Nedloh
It uses the CompareFileTime function on WIN32_FIND_DATA.ftLastWriteTime of the existing file (So the "new" file needs to be newer than this)
Anders
@Anders: Won't the "new" file always have a LastWriteTime of the current time? Or does it store the LastWriteTime of the file before doing the NSIS compilation and use that to compare?
Nedloh
Actually, now that I think about it, this really doens't explain the issue, why then would installing over a copy of our product that used the NSIS installer work fine. Assuming that this file is modified at various times that the user uses it, then it could be possible for the old file to be newer than the "new" file even with the NSIS install.
Nedloh