Jim’s Random Notes

I updated my Java runtime the other day, and now every time I open a new tab in Internet Explorer, I get this message box:

It looks like somebody at Sun forgot to sign their update agent.  At least, I think this control came from Sun.  But there’s no way to be sure, is there?  Do I blindly assume that this really is from Sun and that they made a mistake in generating the build, or do I do the prudent thing and permanently disallow it?

In a security conscious world, there’s no excuse for a major player like Sun to have released something with this error.  One wonders, if an obvious bug like this makes it through their quality control, what other less obvious nasties are lurking in the code.

To heck with it.  If Sun wants to push their software on me, they’ll have to get it right.  I’m going to disallow the update agent.  If I ever need to update my Java runtime, I guess I’ll just have to do it manually.

I discovered last week that somebody had hacked my blog and added a bunch of link spam at the end of the footer script. For some unknown period of time, all of my blog pages contained hundreds of spam links–mostly for prescription drugs. But nobody saw them.

I don’t understand why it was done that way, but the links were invisible in browsers. At least they were invisible in the browsers that I use, and none of my regular readers sent me a message notifying me of the spam. I found out about it when I upgraded my WordPress to the latest version. After the upgrade I was checking out the footer script and discovered all those lines.

I know that it was there on May 22–the last day Google crawled the site. Their stats for my site show that prescription drug terms are the most prevalent terms on my site. I guess I look like a link spammer now. I hope they crawl again soon.

The most important lesson I learned here is to pay attention to the Dashboard when I log in to WordPress–especially when it contains warnings about vulnerabilities and upgrades. I hadn’t upgraded in many months, and was several releases behind.

I don’t know what exploit the malefactors made made use of in order to change my footer.php file, but I’m pretty happy that’s all they did. I suspect they could have modified any of my WordPress files and really made a mess of things. I don’t think they actually compromised my WordPress administrator account or my account with my ISP, but I changed the passwords anyway.

This morning I was sitting in my office, listening to music and banging away on the keyboard like a good little programmer, when I heard a very loud BANG. The first time I heard that–a couple of weeks ago–I was running the dishwasher and thought something in there had made the noise. It wasn’t until one of the other guys came in a few hours later that I found it was a soda can that had exploded in the refrigerator.

So I knew what the sound was when I heard it this morning. What surprised me was how the can exploded. This is the first time I’ve seen the top blown off of a can. Every other exploded soda can I’ve seen had a split on the side somewhere. This one is intact except for the cleanly-removed top. Oh, and the bottom is bulging.

When the last can exploded, we adjusted the refrigerator’s temperature in an attempt to prevent this from happening again. Apparently that’s not good enough. It appears that the freezer vents into the refrigerator, and there’s a spot just below that vent (back, center, top shelf) that gets the benefit of that cold air. So much benefit, in fact, that it’ll freeze a can of Coke Zero.

New rule: no drinks on the top shelf.

Note: No, I’m not the Coke Zero drinker. I prefer the real thing.

This afternoon, the program that adds records to my database started timing out on every transaction. Although I could connect to the database and execute queries, all updates would time out. When I logged in to the SQL Server machine, I noticed that it was responding very slowly. It took a few minutes of poking around before I finally hit on the idea of checking the event log. There I found this message, which was repeated every two minutes:

Autogrow of file ‘Media_log’ in database ‘Media’ was cancelled by user or timed out after 120032 milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.

The log file was set to grow automatically by 10% whenever it gets full. What I didn’t realize is that growing the log file involves more than just allocating another bunch of sectors from the disk. Whatever SQL Server does to grow the log file takes longer than two minutes when the log file is 100 gigabytes in size. To make matters worse, my update program had over 40,000 updates pending and no way for me to store them on disk for later. An oversight on my part, I’ll admit. When you’re blowing and going trying to get something up and working, you tend to let silly things like disaster recovery fall by the wayside.

I tried a number of different things before I took a stab in the dark and decided to create a new log file, hoping that SQL Server would give up on the old overflowed file and write to the new one. Fortunately that worked and my data is now safely ensconced in SQL Server and backed up.

I obviously have a bit to learn about administering a SQL Server installation. For now, I’ve backed everything up and am in the process of shrinking the database before bringing my application up again. Tomorrow I’ll be reading up on the different recovery models and implementing a regular backup schedule so I don’t have to go through this again.

You’d think that published documentation would be checked for correctness.

I’m just getting started writing the code that parses files that use Microsoft’s Advanced Systems Format (ASF), and I ran across a rather confusing bit of documentation.

The Header Extension Object contains 46 bytes of header information and then a variable-length byte array of additional data. In the description of this object, there are these two tidbits:

Object Size - Specifies the size, in bytes, of the Header Extension Object. The value of this field shall be set to 46 bytes.

Header Extension Data Size - Specifies the number of bytes stored in the Header Extension Data field. This value may be 0 bytes or 24 bytes and larger. It should also be equal to the Object Size field minus 46 bytes.

This is plainly impossible. If Object Size must be 46, then Header Extension Data Size has to be zero? But then you can’t have any data. Odd, that.

I’ll have to examine a file that contains one of these objects to be sure, but I suspect the Object Size field will contain the size of the entire record and Header Extension Data Size will indeed be (Object Size) - 46.

I can understand making a mistake in documentation. I’ve certainly made my share. But I can’t be the first person to come across this error since the ASF documentation was last revised in December of 2004. Why hasn’t Microsoft updated their document?