The problem is that some of the existing files can't be overwritten. This one, for example: D:\read\Logos4\System\es-MX\Logos4.resources.dll
You need to make sure you have r/w access to all the files in D:\read\Logos4\ before attempting the install.
Mark is right, right-click on the Logos4 folder and hit properties and ensure that you have all permissions set on this folder and the sub files and folders. It might be the case that you don't have the read and write but not modify property set
Thanks for the responses, but checking the properties of the "es-MX" folder shows the "Read-only" box coloured in, and clearing it makes no difference. I can delete the file "Logos4.resources.dll", and paste it back without any issues. The file is not "read-only", but the installation of the update refuses to go any further.
Then can you delete the file and re-run the installation? Make sure logging remains turned on so we can diagnose further problems. Also, make sure you read my comments at the beginning of this thread which said "You should make sure you run Logos with the same privileges you had when you installed it. If you install as admin, then run as a user you can get problems."
Hi Mark, I had already tried deleting the file, but no joy. Your last remark however did the trick. Running L4 as Administrator seems to have resolved the issue. I normally run my system as admin., but for some reason explicitly choosing run as admin resolved the update problem.
Thanks
Mark Barnes: The problem is that some of the existing files can't be overwritten. This one, for example: D:\read\Logos4\System\es-MX\Logos4.resources.dll You need to make sure you have r/w access to all the files in D:\read\Logos4\ before attempting the install.
To summarize about this permission failure:
If I attempt to launch Logos 4 (the previous version before the update) as some other user, then it doesn't trigger the update and the previous version runs fine. If I launch Logos 4 as myself (without using "run as...") then it triggers the update and fails.
I am a software engineer by profession and generally familiar with file permissions and I don't think that has anything to do with it. It says "Error writing to file" and creates a DLL file with size zero. But the file and directory have complete write permission to me.
So I'm still at a loss to explain what's wrong with the update. If I uninstall Logos 4 and then reinstall it (so that it gets the latest version during the install), that works fine. Its only at the point of the subsequent automatic update where trouble begins.
I should also clarify that I'm running XP home edition on this particular machine, and as far as I can tell, there is no way to "run as... Administrator" since there is no "Administrator" account listed within XP home. (There are three accounts on the machine, all which have Administrator privileges, but none of which are the Administrator. I'm less familiar with XP home--usually using XP professional--so I'm not sure how or even if I can try to "Run as..." Administrator since there is no apparent Administrator account on the machine.)
Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4
I found out that Windows XP home edition disables the ability to login as "Administrator" except when running in Safe Mode. (The idea is that you only login as Administrator in Safe Mode to fix one of the other accounts--which can have Administrator privileges--and then boot back to normal mode.)
http://windowsxp.mvps.org/admins.htm
So I tried a couple of additional experiments:
All this to say that my few attempts to try to run Logos4 (and especially the update) as Administrator under XP home have been futile. Then again, I have no real indication that this would fix the problem I'm seeing in the first place since I have Administrative rights and Logos4 was initially installed under my account directly from the crossgrade CD.
To summarize: the update always fails with a zero-sized DLL which is successfully created in the correct directory--both the directory and the file itself are writable by me. So the error writing the file must be due to something else. Since I'm unable to run Logos4 as Administrator under Safe Mode in XP home (and Administrator is unavailable outside of Safe Mode), I can't investigate whether running as the one-and-only Administrator would cause different behavior.
The question remains why the update reports an error writing the updated DLL, but successfully created the file itself (although empty) and is also successful at backing out the changes (deleting the zero-size DLL and restoring the original DLL) after reporting the error and I cancel the update.
Anthony Garland:All this to say that my few attempts to try to run Logos4 (and especially the update) as Administrator under XP home have been futile.
Is D:\ a fixed partition or a removable HDD? How did you create the D:\read folder (from your Admin account?)
The only way might be to re-install from your Admin account - but we can avoid downloading if you study Method 3 at http://wiki.logos.com/Quick_Installation_onto_multiple_computers (the "working installation" is your current installation!).
Dave===
Windows 10 & Android 8
Anthony,
Sorry you're still having trouble with this. A couple of points:
I hope this makes sense, and helps you solve the problem. Do let us know.
Thanks for the various suggestions.
Anthony, how did you set the permissions for users in XP Home? The way I remembered it on my notebook is that I never saw any security settings on my version of xp home edition. To be able to make that tab visible, I had to download a utility from Microsoft.
If there is a "user group" with deny permissions, that will deny the administrators also. And maybe you might also need the "SYSTEM" account with all permissions set to allow also. A lot of times I saw installers fail if the "SYSTEM" account wasn't set on the folder or files that needed to be replaced.
I'm at a bit of a loss, I'm afraid. I'm going to take a wild guess, and if this doesn't work, suggest you contact support.
The wild guess is the the installation file doesn't like the folder called READ. Googling suggests that the first error that is being returned by the installer (2318) can sometimes occur when a reserved word is used in the pathname. I don't have any more details than that, and I'm not an MSI expert, I'm afraid. But it may be worth a try.
Mark
Problem solved!
I restarted in safe mode and logged in as Administrator and double-checked the permissions one more time. As I saw before, my normal login identity "tony", which has Admin rights had both ownership and full control permissions on every directory from D: all the way down to D:\read\Logos4\System\es-MX.
I repeated what I had done previously: set both Administrator and SYSTEM permission at D:\read and told it to propagate the permissions to child folders and files (and then watched as it took several minutes to visit all the folders and files setting the permissions). What was strange, though, was that when I browsed below D:\read again looking at security, neither Administrator nor SYSTEM appeared in the list of users. For some reason, these permissions were not propagated down as one would have expected.
I double-checked d:\read\Logos4 and saw something odd there that I hadn't noticed earlier:
I began to wonder whether these odd users were somehow interfering with the propagation of access permissions I had attempted earlier. So I deleted both of them from the list of users, went back to D:\read and then gave recursive permission for Administrator (user), SYSTEM (user) and Administrators (group) down the entire D:\read tree once again. This time, the permissions propagated all the way down D:\read\Logos4\System\es-MX and this fixed the problem.
So even though "tony" had the necessary permissions as an Admin, the other bogus users were somehow preventing Administrator, SYSTEM, and Administrators from being granted access each time I set these at a higher level and attempted to propagate the security settings downward.
And even though the update was running as "tony" with Admin permissions and complete control over the entire path down to D:\read\Logos4\System\es-MX\Logos4.resources.dll, something more was needed. I'm not sure if granting SYSTEM, Administrator, or Administrators permission was the key as I didn't do them one-at-a-time. But the main thing is it is fixed now.
I'm grateful for the patience and suggestions made by those who attempted to point me in the right direction to correct this glitch.
- Tony
Anthony Garland:I'm grateful for the patience and suggestions made by those who attempted to point me in the right direction to correct this glitch.
Glad it is fixed, Tony.
Enjoy the coming New Year!
Thanks for reporting on this issue Tony I'm sure other users may find it helpful, glad you got it working!
George and Tony,
I am one of the "other users". I have gone round and round with security access / user rights / adminstrator ..... I still can't get the update to get past the same hurdle as Tony.
Stephen Miller
Sydney, Australia
I now remember a change I made recently .... When I installed Windows 7 .... when windows started my User Icon popped up on the screen. This meant that Windows wouldn't start until I had clicked the icon.
Somehow I changed this so that Windows starts directly I switch on the computer.
I guess this has affected the user rights in my Logos 4 folder.
Sydney, Australia.
I switched off UAC, restarted Windows 7 and the update ran through.
StephenMiller02: I now remember a change I made recently .... When I installed Windows 7 .... when windows started my User Icon popped up on the screen. This meant that Windows wouldn't start until I had clicked the icon. Somehow I changed this so that Windows starts directly I switch on the computer. I guess this has affected the user rights in my Logos 4 folder. Stephen Miller Sydney, Australia.
This is interesting, glad you got around the problem.