I've previously tried 6.n.n clients, and found them unacceptable to me. So I mostly had 5.10.45 with a couple of 5.10.20's in my small flotilla. Following advice in this thread, for people in my circumstance, I backed the 5.10.45 hosts down to 5.10.20 about a week ago after losing a good bit of work in the recent project downtime.
However, for one of my hosts which used to have a nasty habit of killing all four executing tasks on the first project communication after client restart, and some other bad behaviors, that pattern returned with my reversion to 5.10.20. So for that single host I've decided to prefer the risk of occasionally losing a lot of work on a project site outage to the daily drain of poorer behavior.
I post this just in case someone else may have such a host, and find this shared experience useful. By the way, I have no idea what the special problem is on that one host. All my machines run WinXP Pro, and generally carry a pretty similar load of other software. One even shares the same model of motherboard with this one. So quite likely the root problem is a configuration issue on my discrepant host, to which 5.10.20 reacts less gracefully than 5.10.45, rather than an outright 5.10.20 bug later fixed.
Yes, I agree. I too do not want to put 6.n.n on all of my machines. Further, that is not necessary to avoid this problem, as I said in my posting:
Quote:
...it was not due to user error and could have been prevented by proper operation on the server side...
This was noted by Gary on 31 Mar 2009 when he stated:
Quote:
I was amused by the implication of the final comment that the problem could be caused by project staff not shutting down the file upload handler by the approved method :-). I imagine it's a bit hard for staff to follow "approved procedures" if all is violently crashing around your ears :-).
So, it's clear enough that the problem can be avoided by project staff. But it wasn't -- perhaps understandably, but it wasn't. So... What does this mean? It means that it is not necessary to switch to 6.n.n, and it therefore further means that we are entitled to our missing credits.
RE: I've previously tried
)
Yes, I agree. I too do not want to put 6.n.n on all of my machines. Further, that is not necessary to avoid this problem, as I said in my posting:
This was noted by Gary on 31 Mar 2009 when he stated:
So, it's clear enough that the problem can be avoided by project staff. But it wasn't -- perhaps understandably, but it wasn't. So... What does this mean? It means that it is not necessary to switch to 6.n.n, and it therefore further means that we are entitled to our missing credits.
--Bill