« Last post by mouser on April 11, 2011, 04:40 PM »
loss of packets is quite possible -- but normally in this case doesn't the browser detect that it is having communication problems and stall, etc. I mean thats what i see happen when we know there is a packet loss issue. The result is slow downloads not corrupted ones.
« Last post by mouser on April 11, 2011, 04:24 PM »
The thing i find strangest is that the browser is not figuring out that the download is incomplete.. that's what's really throwing me for a loop -- i mean normally the browser knows when a connection has failed, etc. What's particularly bizarre in this case is that the browser and server are somehow convinced that the download has fully finished successfully.
« Last post by mouser on April 11, 2011, 08:05 AM »
We've always had an occasional occurrence of this problem, but it seems to be getting worse lately.. Someone will try to download a program from our website (main or member server), and when they try to run it, they get an error saying its "not a valid win32 application" or "The setup files are corrupted".
Worse yet, if they try to re-download the browser gives them the cached half-finished download again so the problem recurs and they are left very confused and thinking the software is defective.
A search on the web shows that this does happen enough to everyone that the problem is well known
But my question is: Does anyone have any server experience who can help us understand how to fix this problem on the server end -- to stop this from happening so often? What is causing downloads to fail half way through, and leave the browser thinking the download is complete? And how can we fix this on our server end?
Does anyone have any server running experience have any idea? Help!
« Last post by mouser on April 11, 2011, 12:16 AM »
i don't mean to push my feelings on anyone.. but do we maybe think the points on this thread have been hashed out several times over, and maybe it's time to move on? just a thought.
« Last post by mouser on April 08, 2011, 05:39 PM »
BINGO.
You have edited your configdir.in file and told FARR you want it to run in portable mode and to save its settings to its current directory. BUT you have placed it in a directory that windows7 will not allow it to save to.
That is the cause of your problems.
If you want it to run in portable mode and/or save its settings to its own directory, you MUST install it in a directory that it has write access to.
Mystery solved. I suppose a clearer error message though would make this easier to diagnose in the future.
« Last post by mouser on April 08, 2011, 02:44 PM »
And how did it get installed into C:\Program Files\ on windows 7? It should have installed into C:\Program Files (x86).. It's almost as if it doesn't know its running on Windows 7..
« Last post by mouser on April 08, 2011, 02:31 PM »
yes we sure are.. the main question is.. why is it trying to work with a settings file in C:\Program Files\ if you are on Win7. That is the heart of the problem.
Do you have a configdir.ini file in your C:\Program Files\FindAndRunRobot\ directory? can you paste here the first few lines in that file?
Unpack it over your existing FindAndRunRobot.exe and run it.
It should create a debugout.txt file in your documents \donationcoder\findandunrobot directory or something like that. I guess what you want to do is run FARR, change a setting, and then exit. And then check out that debugout.txt file and search for "IN SaveSettings"