12.09.04
65535 no longer a big number.
I came across rather an interesting thing yesterday. I provide support for some local businesses near me and I got a call from one to say that Adobe Acrobat on one of their machines was no longer working.
I didn’t worry about it too much, assuming that I could come in take a look, maybe reinstall Acrobat and all would be well. This business is one that has a regular need to view pdf files, so this was a problem rather than just a nuscience.
I arrived at the clients offices and got started. First off after some initial investigation, I downloaded the most uptodate Acrobat from the web and reinstalled it. No luck. Uninstall, shut down , Reinstall. No Luck. 
It kept hanging on startup, just got to the rather funky splash screen that Acrobat has and no further. After all the reinstalls I realised there was something more going on. A quick search on google let me to this discussion, by people who were having the same issue. I glanced through it until I came to what was probably the root cause of the problem. Temp files.
Like many of the people chatting in the discussion this computer had 65,000+ files in the root folder of the temp directory. 65,000 of which were acrobat *.tmp files. A possible cause for the problem was suggested by one of the participants in the discussion. 65535 is FFFF in hex, all the tmp files in the directory created by acrobat had 4 letter hex number ie, acr****.tmp. One more file and an overflow occurs, preventing the application from ever starting again.
This raises several questions.
- How did Acrobat manage to generate 65535 tmp files in a realatively short period of time? The pc was only 6 months old – thats approx 360 tmp files a day. Even in a pdf intensive office thats a bit excessive.
- Why didn’t acrobat delete its temp files?
- Why not just overwrite acr0001.tmp when you reach acrffff.tmp?
- Why not fix the problem in the next version?
Needless to say I followed the advice of the participants and deleted all these files. Low and behold Acrobat worked again. We’ve all made the mistake of assuming that a ‘magic number’ we place in our code will never be reached, but we should all write code that ensures it never is.
