|
The ghosts of the past won't let me rest. My former boss informed me that our project web page "was broken. At least, it is not listed as a malware site on Google".
Well, last thing happened to us last year after a hacker attack (see http://www.codeproject.com/Messages/4323984/Analysing-an-obfuscated-malware-script.aspx[^]).
Since that project was my best piece of work (seriously, not in the satirical meaning of the rest of this post, and despite the code shown below), I immediately looked into it: the home page loaded smoothly. Nothing wrong. The next pages also. So, what was wrong? I tried an aspx page. Worked. Next aspx page, and here it was:
Error: Access violation. File exists. at
strFileName = System.IO.Path.GetTempFileName
The page creates an image dynamically, based on user input. The image is written into Graphics folder of the web site. After the web site was moved to a different server, the clean-up process for that folder failed due to a lack of access rights. But that was long ago. I looked into that folder, and it was empty.
But wait, that line mentioned in the error message does something different!
Before the temporary image file is created, I ask Windows to give me a file name. I created such a superb function for that purpose:
Public Function getTempFileName(Optional ByVal Extension As String = "tmp") As String
Dim strFileName As String
strFileName = System.IO.Path.GetTempFileName
strFileName = strFileName.Substring(System.IO.Path.GetTempPath.Length)
If Extension <> "tmp" Then
strFileName = strFileName.Substring(0, strFileName.Length - 3) & Extension
End If
Return strFileName
End Function
Overwhelmed by the beauty of this piece of code (it will surely be honored as the proper solution to that problem in many VB and aspx fora throughout the web soon), you'll likely not see how this function can fail. Also I had to take a look into Microsoft's documentation:
Not only does System.IO.Path.GetTempFileName return the full path for a temporary file, it does also create it! And yes, Windows must do so to ensure that two programs do not share one temp file. I took the filename only, never did I care for that file. And somewhen Windows run out of temp files...
|
|
|
|
|
Oh.. it's considered a standard practice to delete the temp file after use... so, i'll say it's coding fault! Please, no offence
I don't rely on the get temp file though, I have my own random naming algorithm, kept locked highly in my hard drive with several layers of ultra military grade encryption! !
|
|
|
|
|
|
Amitosh Swain wrote: i'm thinking to leverage it into a javascript ofuscator! Uhm, so... the next "hacker's script" will be yours... or maybe this one was! <hides his IP under the desk>
Greetings - Jacek
|
|
|
|
|
Jacek Gajek wrote: Uhm, so... the next "hacker's script" will be yours... or maybe this one was
I'm not that good at breaking anything... anything means anything...
|
|
|
|
|
|
|
Yeah, two times substring instead of the functions of System.IO.Path - 9 years ago I did not know them.
But you see: you'd fix the substrings, not the failure. The beauty of this gem prevents you from really fixing the problem (e.g. strFileName = Guid.NewGuid().ToString() & "." & Extension )
|
|
|
|
|
This one's a lesson in why reading the documentation can be helpful. GetTempFileName states that it creates the file ... somewhat annoying if you want to create a temporary file with a different name (extension), but I guess their point is that the name doesn't matter as it's only temporary.
|
|
|
|
|
If you just want to generate a random filename without creating a file, try Path.GetRandomFileName[^] instead.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
|
As you wish.
Will remove it in next 5 min.
|
|
|
|
|
Sorry unable to delete.
|
|
|
|
|
Found this in a would be production code today ...
public bool InitializeApp()
{
bool bStatus = false;
try
{
try
{
DoStep2();
}
catch (Exception ex)
{
}
try
{
DoStep3();
}
catch (Exception ex)
{
}
try
{
DoStep4();
}
catch (Exception ex)
{
}
try
{
DoStep5();
}
catch (Exception ex)
{
}
try
{
DoStep6();
}
catch (Exception ex)
{
}
}
catch (Exception eError)
{
}
return bStatus;
}
Goes without saying that every DoStep method has a try-catchEverything block with log
If I am still missing the point .. its the nested try-catch I am pointing to
modified 30-May-13 23:02pm.
|
|
|
|
|
I've had to do that in certain circumstances. Use the right tool for the right job.
|
|
|
|
|
Can you elaborate? I find it hard to conceive of a situation where that would be necessary, but am willing to be proved wrong.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
What came to mind was a Windows Service I wrote a few years back that had to perform a number of related, but not dependent, tasks.
An analog that also came to mind was babysitting... the babysitter will have a number of tasks:
0) Check the kid's homework
1) Feed the kid
2) Put the kid to bed
A problem in one task doesn't mean you can't perform the others:
If the kid doesn't do the homework or has errors, you still feed him.
If the kid doesn't eat his vegetables, you still put him to bed.
Just log it and continue. If the problem is bad enough, alert the parents, but don't go running out of the house.
|
|
|
|
|
Food is a reward for doing the homework. I will be a terrible parent.
Greetings - Jacek
|
|
|
|
|
It's not that bad, unless each step depends on the previous step completing successfully, in which case there's no reason to run the rest when you know they will fail.
|
|
|
|
|
Well, I always have an Uncaught Exception Handler. I program mostly in Java and C# and I don't like any hangs or crashes. get an uncaught handler, if at all an exception occurs, (yes... I give heed to LogException too) if is shown as -
"POSSIBLE BUG... Please help us to fix it by sending a brief bug report"...
|
|
|
|
|
I also like the fact that it will always return false . Did you miss this most important feature?
|
|
|
|
|
) good eyes
|
|
|
|
|
Looks like
on error resume next
|
|
|
|
|
One use for such a structure would be to fully log the error without having debuging info in the compiled form.
If that is the case, then the outer try/catch would be the unnecessary one, not the internal ones.
|
|
|
|