Installing/Updating from 4.0.4 to 4.0.5 - Error with DragExt

During updating to the new version an error occured. the installation program could not overwrite the existing DragExt.dll.

My workaround:

1. Manually deinstall the DragExt.dll with the command:
   
   regsvr32 /u {path to winscp}\DragExt.dll
   
   
2. Restart Windows
   
   
3. Now Updating works!
   

Under Windows XP Pro I am logged in as "main user" (german Hauptbenutzer) and not as an Administrator.

cu, helpy

Do you have a full error message? The setup should not have a problems with this. It should schedule replacement of the DLL on the next windows restart automatically.

Does anyone have the same problem?

During installation (full upgrade) a message box shows up with following content:

Title:

Error

Message text:

C:\Programme\WinSCP\DragExt.dll

An error occured while trying to replace the existing file:
DeleteFile failed; code 5.
Access denied.

Click Retry to try again, Ignore to skip this file (not recommended), or Abort to cancel installation.

Retry ... results in the same error

Ignore ... will install all the new files except DragExt.dll.

Abort ... cancels the upgrade

cu, guido

Thanks. What version of Windows are you using?

martin wrote:

Thanks. What version of Windows are you using?

Windows XP SP2 German

Hi. I have the same problem upgrading 4.1.6 to 4.1.7 with the exact same error message. I have not yet tried any resolution, but uninstalling 4.1.6 and then installing 4.1.7 should works since DragExt.dll would be removed during the uninstallation (or upon reboot).

The problem seems to be that this file is in use at the time of upgrade, so it should probably be scheduled to be overwritten upon reboot.

Edit: I'm using a regular (non-administrative) account -- the same that I used to install 4.1.6.

angel_tsankov wrote:

The problem seems to be that this file is in use at the time of upgrade, so it should probably be scheduled to be overwritten upon reboot.

The setup does that. However I do not know if regular (non administrative) account is able to do this.

martin wrote:

angel_tsankov wrote:

The problem seems to be that this file is in use at the time of upgrade, so it should probably be scheduled to be overwritten upon reboot.

The setup does that. However I do not know if regular (non administrative) account is able to do this.

Yes, you seem to be right: non-administrative accounts may not schedule files to be moved at reboot. In this case, the setup should either:
-- require the user to uninstall any previous version and then install the new one; or
-- require the user to restart the system and log back in to complete the upgrade.

Thanks for your post. This issue has been added to tracker.