Working on an application that was already built before I came to it, I came across this error:

"Image corrupt or truncated: <unknown>"

It only appears in Firebug's console in Firefox (it did not show up in IE or Chrome).

After Googling a bit I found that a lot of people seemed to be blaming it on favicon.ico. As far as the error went though, no line number is indicated and the favicon actually does appear in the Window's title bar/tab.

Thinking that maybe there was something wrong with the format of my favicon.ico, I opened it in Adobe Fireworks to see if it was possibly misformatted in some way and if there was a chance that re-saving it might help. Fireworks told me that it was actually an 8 bit BMP file and I found out through more Googling that ICO files can be made by simply saving your images as a BMP and then changing the file extension to .ico. I repeated this action but still wound up with the same error.

Out of curiosity, I browsed directly to the favicon and noticed that in the window title/tab title the following appeared: "favicon.ico (BMP Image, 20x20 pixels)". So it was actually still being interpreted by Firefox as a BMP image, not an icon.

Confounded I decided that even though this BMP/ICO file extension conversion seemed simple enough, Firefox must be interpreting it differently still. So, resorting to an online ICO file generator (http://www.favicon.co.uk/) I managed to fix my problem. I uploaded the BMP version of my icon (20x20 pixels) and generated an ICO version at a more official icon size of 16x16 pixels.'

Voila! No more error and the title in the window/tab now appears as "favicon.ico (ICON Image, 16x16 pixels)" when you browse directly to the favicon.

PS. Even though browsers these days seem quite capable of picking up a favicon in the root folder of your application, it's always a good idea to explicitly point to it:

<link href="http://[YOURWEBSITE]/favicon.ico" rel="shortcut icon" type="image/x-icon" />

What is Epoch time?

"The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but 'epoch' is often used as a synonym for 'Unix time'. Many Unix systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038)."
- epochconverter.com

What am I talking about?

In recent work I came across a database table that was storing Epoch timestamp values. I'm sure there are other UDFs out there to convert Epoch timestamps to a readable disply format, but I thought I'd give it ago anyway.

I came across a ColdFusion Cookbook sample that fit the scenario perfectly, written by Rob Brooks-Bilson. It explains the process of converting an Epoch seconds timestamp to a Date object. This was my base.

With a few additions, my UDF became (apologies for the formatting):

Example usage:

Example output:

7-Apr-11, 3:51:25 PM
(where the Epoch seconds value from getTickCount() was 1302155485932)

UPDATE:

Thanks Damon for your comments below regarding an alternative approach that will allow you to display a date/time including milliseconds, by utilitsing Java's Date class directly. Applying the changes Damon has suggested, we end up with the following version of the UDF:

Example usage (added millisecond mask 'L'):

Example output:

11-Apr-11, 2:11:58:714 PM
(where the Epoch seconds value from getTickCount() was 1302495118714)

Download (.zip): demo & source (includes three variations of the UDF)

A few notes:

• As far as I know, since ColdFusion MX getTickCount() has been returning an Epoch seconds timestamp value. The length of this value is 13 digits. In this UDF and the ColdFusion Cookbook example (in the comments regarding Java Epoch) you should note that Left(str,10) is used to trim the Epoch numeric string value to the required 10 digits in length.
• I'm not sure if getTickCount() returned am Epoch seconds value before ColdFusion MX.
• Thanks to Damon's comments (below) it has been pointed out that Java's Date class can be utilised instead, to get the same result. Taking this route also means trimming of the Epoch value down to 10 digits is not required - allowing you to use the full 13 digit Epoch millisecond value. This will of course also now allow you to display milliseconds if you wish.
• If you are running your site on a shared host that disables the use of CreateObject('Java') (ie. GoDaddy, Net24, and many others unfortunately), the second UDF is not for you. The first one should work though.
• The image in the post obviously has nothing to do with Epoch. Although, when I say "Epoch" in my head it always reminds me of Ewok.

For what it's worth, the inclusion of CFSpreadsheet and all the associated functions in ColdFusion 9 is a very welcome update. It's enabled me to generate some very complex and impressively formatted documents with relative ease.

One thing I'm working on requires my client to send me import data spreadsheets that I run through the new application (in development) and pull into the database. One particular file happened to have a password associated with reading it - total brain fart that I missed this. I even opened it previously when first receiving it with the password and it didn't twig. So duh to me.

Anyway, using CFSpreadsheet to read this file in quickly ends with the error response:

An error occurred while reading the Excel: java.lang.IllegalArgumentException: The supplied POIFSFileSystem does not contain a BIFF8 'Workbook' entry. Is it really an excel file?.

Oh as a side note, I love how the error message actually asks me a question. It's like it has a sense of humour. I even attempted opening the file in WinRar and got an error message that was just as vague.

As you can see it's not really the most helpful of error messages but to cut a long story short it is the result of the file have password protection. I would have assumed that a password protected file would come back with an authentication error message, but maybe the POI libraries are vague on this when throwing the error. I imagine maybe the data is encrypted which is not recognised                  until Excel loads the contents of the file, hence prompting you to enter a password. Who knows.

Oddly, it seems that write and update actions for CFSpreadsheet have attributes for using a password, but not read. Anyone please let me know otherwise as it would be helpful (CF9 Docs http://goo.gl/QDwM).

So, the lesson learnt. Yes, always check "Is it really an excel file?" and of course keep in mind that password protected files might also cause vague misleading error response messages. It does make sense of course than error would be thrown and I should have checked first to see if the file had a password first. That would have solved my problem right off the bat!