by mikerowley » June 4th, 2012, 12:38 pm
I can try to create a sample that does it, but it only happens on about 20-30% of my 120 machines that use the updater so odds are against it being easily reproducible. It seems absurd to me that there is no fallback plan if the "temp" directory cant be found, it manages to create an error message telling me what is happening (and I would assume telling you exactly where in the code it is failing) and if it fails the software cant be smart enough to create a temp directory to avoid failing completely, which ostensibly orphans a service with absolutely no ability to update itself, which is required to repair the problem even if there is a solution.
It just seems to me this should be a little more robust than this if it is an "automated" update solution.
As it seems to be a low percentage chance that I am going to be able to reproduce the problem, let alone reproduce it in a dev environment and even if I manage to get it reproduced on my side, even less chance of reproducing it on your side.
Seems like a waste of time to me when it is such a simple thing that is broken in your software.
I'm sorry if this seems like a rant, it is not intended as such but simply an accurate description of the reality of what you guys are building and the lack of robustness that seems to have crept into the code. Which will lead to me having to manually update at least 30-40 computers remotely because the updater cant create a temp directory to do its thing with. Seems like an oversight to me. And one that has been a problem in the past as I have seen this error in other forum posts.
Why can't the updater use a "standard" temp directory (c:\windows\temp) that everything else in windows uses? Or create its own? Or allow the user to specify its own if the previous options are not sufficient?
I can try to create a sample that does it, but it only happens on about 20-30% of my 120 machines that use the updater so odds are against it being easily reproducible. It seems absurd to me that there is no fallback plan if the "temp" directory cant be found, it manages to create an error message telling me what is happening (and I would assume telling you exactly where in the code it is failing) and if it fails the software cant be smart enough to create a temp directory to avoid failing completely, which ostensibly orphans a service with absolutely no ability to update itself, which is required to repair the problem even if there is a solution.
It just seems to me this should be a little more robust than this if it is an "automated" update solution.
As it seems to be a low percentage chance that I am going to be able to reproduce the problem, let alone reproduce it in a dev environment and even if I manage to get it reproduced on my side, even less chance of reproducing it on your side.
Seems like a waste of time to me when it is such a simple thing that is broken in your software.
I'm sorry if this seems like a rant, it is not intended as such but simply an accurate description of the reality of what you guys are building and the lack of robustness that seems to have crept into the code. Which will lead to me having to manually update at least 30-40 computers remotely because the updater cant create a temp directory to do its thing with. Seems like an oversight to me. And one that has been a problem in the past as I have seen this error in other forum posts.
Why can't the updater use a "standard" temp directory (c:\windows\temp) that everything else in windows uses? Or create its own? Or allow the user to specify its own if the previous options are not sufficient?