I'm using ver 2.2.2.0 with Delphi 2009. I develop on Win 7.
I've used TWebUpdate with no problems for years with different aplications. Recently however some of my users are saying their applications are no longer updating. Apparently they get my message saying it is looking for an update but it never seens to download either the inf file or the update cab.
I've got one user doing an update log for me at the moment but I've noticed that all the ones failing seem to be those who have upgraded to Win 8 or Win 10.
Anyone else had this problem and anyone got any ideas for a solution?
In case its any help to anyone this is the log that the user is getting.It seems to be failing renaming a file but I don't know what that file is or why it can't be renamed.
27-09-2015 09:06:48 : [918] Checking for Internet connection (Status:3) (Error:0)
27-09-2015 09:06:49 : [921] Found open Internet connection (Status:3) (Error:0)
27-09-2015 09:06:49 : [923] Connect to host : c9999999.myzen.co.uk (Status:3) (Error:0)
27-09-2015 09:06:50 : [915] Download : MAMbase.INF (Status:3) (Error:0)
27-09-2015 09:06:50 : [974] Change FTP directory to : /ApplicationUpdates/MAMbase (Status:3) (Error:0)
27-09-2015 09:06:50 : [973] Cannot rename file : .\WUP91EB.tmp to .\MAMbase.INF (Status:19) (Error:7)
Unable to rename file .\WUP91EB.tmp to .\MAMbase.INF
27-09-2015 09:06:50 : [925] Update control file not found (Status:2) (Error:0)
27-09-2015 09:06:50 : [954] Closed FTP connection (Status:3) (Error:0)
27-09-2015 09:06:50 : [949] Closed Internet connection (Status:3) (Error:0)
27-09-2015 09:06:50 : [949] Closed Internet connection (Status:3) (Error:0)
There are no known issues with Windows 8 or Windows 10.
What are the settings for TWebUpdate?
Did you specify a temp folder? Where is the application installed?
The issue looks like a problem with permissions to write into a specific folder or something is keeping the file mambase.inf locked.
The issue looks like a problem with permissions to write into a specific folder or something is keeping the file mambase.inf locked.
There are rather a lot of settings, nearly all left at the default setting but some of them are
PostUpdateInfo.enabled = false
SignatureCheck = false
UpdateConnect = wucNoConnect
UpdateType = ftpupdate
FTPPassive := true;
URL := 'MAMbase.INF';
UpdateType := ftpupdate;
Use CRC32 = false
VersionCheck = vcUpdateOnly
UseWinTempDir = false
I don't belive that I actively did (some of the applications are quite old and I haven't looked at the update side of them for a while). However since UseWinTempDir = false then I guess they aren't using a temp folder
I have no idea. In common with most applications the installer allows each user to put the application anywhere they like. It isn't one application, at least three different applications with different users have all started to behave like this (although with the exception of FTPPassive they probably all use the same basic settings for TwebUpdate). If they used the default install settings then it would have gone to the 'Program Files (86)' folder or whatever that folder is called in Win8 and 10.
That's what I thought, but it must be a permission that has changed between win 7 and 8/10. At least one user has been updating for many years until they upgraded their server to Win 8 and then it stopped updating. Another user installed the same application on an XP and a Win8 machine . The XP one updates but the Win8 doesn't.
It would be useful to know what change is necessary to the way I use TWebUpdate to avoid hitting this permissions thing.
(Sorry about posting to direct support as well as here, I had received no forum replies when I posted to direct support and anyway didn't realise that TMS people read the user forum. Its good that they do. The user forum for many products is usually just the blind leading the blind!)
The first thing I'd suggest to try is to set UseWinTempDir = true and see if this helps. The default Windows temp dir should have sufficient privileges to download the file to.
UseWinDir is set to false because of suggestions made earlier on the codeverge forum and direct emails from you (Bruno) around 11th Jan 2015 .
These indicated it needed to be false in order to upgrade both an exe plus other files which were in different folders. See (http://codeverge.com/embarcadero.delphi.tools/anyone-use-twebupdate-from-tms-i-nee/1064221) These communications suggested that in order to upgrade an exe plus also some help files in a different folder I neeeded to:
Set the property UseWinTempDir to false
and
NOT flag the extra files as being application components in the INF file
I will try changing the UseWinTempFile to true but I am pretty sure that will stop the help files being updated as that was what happend in January.
Where exactly are the files located to be updated?
Is this folder having sufficient write-permissions?
The files will be wherever each user elected to put them during the install. The default would have been Program Files (86) - or whatever Inno Setup detected as being the program files folder on the taget machine. I can assume that if they had permissions to do the install at that location then they had - at least at the time of the install - write/delete permissions to that folder. As I said many of the applications have been updating perfectly well until the user upgraded their OS. I'm afraid I cannot ask my users what permissions thay havenow as many would not understand the question let alone be able to provide the answer.
However another of my applications is installed on a server simply in an ordinary folder to which I have full control. That program ceased to update when the owner of the server upgraded it to a later OS.
Another idea,
could you check in your app if the file .<span style="line-height: 19.6px; : rgb251, 251, 253;">MAMbase.INF already exists and if so, delete the file just before you start the update process?
Will the file, if it exists, always be in .\ ?
I have just set UseWinDir to true, compiled the program and sent a fresh install to one user so will the inf file still be in .\ for them or will theirs now be in the windows temp folder for that one user? - I guess I could make my app always look in both places just in case.
I'll give it a go, luckily that user doesn't yet object to doing a new install every day!
My user ran the application with UseWinTempDir = true but the logs still indicate the same error
27-09-2015 09:06:50 : [973] Cannot rename file : .\WUP91EB.tmp to .\MAMbase.INF (Status:19)
They have checked their AV and firewall and all is OK there. Indeed the logs indicate that it downloaded MAMbase.inf OK - I suppose to Windows temp but the logs don't say. But that would surely mean that MAMbase.inf wouldn't have existed before anyway or if it did then it was overwritten with the download so deleting it beforegand wouldn't make any difference. Can you explain the invovement of WUP91EB.tmp?
I'll try doing the delete file thing with this very accomodating user.
Interestingly on my delevopment machine (win7) where it updates fine, the logs don't show any reference to renaming a file so I don't know if the temp file made by TwebUpdate is always called WUP91EB.tmp or where it is located, also a search found no file called MAMbase.inf other than in the WebUpdatefolder with the UBProj file etc.
It is by design that the file is always downloading using a temporary filename. If all goes without issue, it won't log this.
For not being able to rename the file I can only see 2 issues:
Write permissions in the folder or the file already exists.
Thank you Bruno for the suggestions. It looks like deleting any existing update files before doing the update has resolved the issue. I still don't really understand why old update files should have still existed anyway or why TWebUpdate doesn't delete them itself if they already exist before it tries to do the rename of the temp file but that seems to be the trick. I note that even now the .cab file still remains after an update but on this particular user's machine it seemed the .inf file did as well for some reason.
Anyway, in case it helps anyone else, the code I used to delete any .cab or .inf files from both the application folder and the Windows temp folder is as follows.
/////////////////////////////////////////////////////////////////////////////////////////
function GetApplicationFolder : string; //with trailing backslash
begin
result := IncludeTrailingPathDelimiter( ExtractFilePath(Application.ExeName));
end;
///////////////////////////////////////////////////////////////////
function GetWindowsTempFolder : string; //with trailing backslash
var
tempFolder: array[0..MAX_PATH] of Char;
begin
windows.GetTempPath(MAX_PATH, @tempFolder);
result := IncludeTrailingPathDelimiter( StrPas(tempFolder));
end;
//////////////////////////////////////////////////////////////////
procedure DeleteFileIfExists(Path, Filename:string; var FoundFile, deletedFile : boolean); //path with or without trailing backslash
var
SearchRec : TSearchRec;
begin
FoundFile := false;
deletedFile := false;
//note see this post if there is a possibility that the path is bigger than 250 characters
//http://stackoverflow.com/questions/16874118/delphi-how-to-check-if-a-file-exists-path-over- 255-characters
if DirectoryExists(Path) then
begin
Path := IncludeTrailingPathDelimiter( Path );
try
if FindFirst(Path + Filename, faAnyFile, SearchRec) = 0 then
begin
FoundFile := true;
try
SysUtils.DeleteFile(Path + SearchRec.Name);
deletedFile := true
except
deletedFile := false
end; //try
end; //if findfirst
finally
FindClose(SearchRec);
end; //try
end; //if DirectoryExists
end;
//////////////////////////////////////////////////////////////////
//delete the cab and inf files from both application folder and temp folder if they exist
//FoundFile and DeletedFile used for logging purposes later
ApplicationFolder := U_GeneralRoutines.GetApplicationFolder; //inc trailing slash
U_GeneralRoutines.DeleteFileIfExists(ApplicationFolder,'MyProgam.cab',FoundFile,DeletedFile);
ApplicationFolder := U_GeneralRoutines.GetApplicationFolder; //inc trailing slash
U_GeneralRoutines.DeleteFileIfExists(ApplicationFolder,'MyProgam.inf',FoundFile,DeletedFile);
WindowsTempFolder := U_GeneralRoutines.GetWindowsTempFolder; //inc trailing slash
U_GeneralRoutines.DeleteFileIfExists(WindowsTempFolder,'MyProgram.cab',FoundFile,DeletedFile);
WindowsTempFolder := U_GeneralRoutines.GetWindowsTempFolder; //inc trailing slash
U_GeneralRoutines.DeleteFileIfExists(WindowsTempFolder,'MyProgram.inf',FoundFile,DeletedFile);
/////////////////////////////////////////////////////////////////////////
Yes, TWebUpdate fails on Win7, Win8 Win8.1 (Win10 not tested). In our Situation the complete Application hang up, cause we checked first if there is an Update (.DoWebUpdate) and not calling a menuposition to start the update. If we call it withhin a menu (Updatewizard) he saw the Update but many times he dos not do it. On a second call App hang up.
TMSSubscriptionmanager is the same. Application hang up.
We examine that, and found out, that it has to do with two updates for IE11: kb3087038 and KB3093983. They modify the files inetres.admx and inetres.adml. I'am not sure if this is all, but if you deinstall this two Updates kb3087038 (He kills it) and the repairtry kb3093983, TWebUpdate and TMSSubscriptionmanager will work again. If you test this out with kb installed, you must test more than once. If we have a fresh booted System we can call the app once eventually twice then the App hang up. After deinstalling this two Updates, we can start our Apps, hundred times and nothing fails.
Our workaraund was, to eleminate TWebupdate in our Application (what a mess), cause we use wsus in our Company and we cannot cancel this updates. I hope, that Bruno can give us a Workaround or an Update to solve this Problem.
A important hint. It looks like that happend only on Systems, that are not pure english. I'm not sure, if it onyl happens on Enterprise Systems in english with language packs (thats in our case) or in Windows in nonenglish.
Regards
Peter
TWebUpdate & TMS Subscription Manager both use Wininet.dll for http & ftp transport. Apparently, something has broken wininet.dll in these KBs. As a workaround we'd suggest to deploy with your apps a working wininet.dll.
As it is very hard to recreate the machine setup for this particular error, perhaps you could send us such a broken wininet.dll so we can test with it and see if there is a workaround (without any guarantee it can be workarounded with a broken DLL)