So if you hadn’t figured it out by now , when I’m not hunting down Sith Lords, I’m hunting down computer issues. With that in mind, I wanted to share an oddball error with you that I ran into recently.
Here’s the story, we had a user that submitted an error that they were getting whenever they tried to download an attachment in outlook. The error is as follows:
Cannot create file: file name. Right-click the folder you want to create the file in and click Properties on the shortcut menu to check your permissions for the folder.
I went out there to take a look at it. Sure enough every time she would try to download the error would appear. So I did what anybody in that sort of situation would do and tried the basics (run as administrator, check the account on the exchange server, etc.). It all seemed in line and wasn’t having an effect,time to take a shot at Uncle Google. By searching Google you are redirected to this helpful little Knowledge Base article. After running through the steps, putting the new folder at C:\temp, and a restart, the user was able to download the files just fine. I figured that for once in my many years of fixing computer problems, a KB article had actually solved the problem flat-out…
About a month later the user calls us back to let us know that the error is happening again. Between myself and 2 other techs, it took us more time then I’d like to admit to figure out what was actually happening.
You see, the user was getting daily reports, in fact she was getting 4 of them a day. 3 of them were XLS files and one was a CSV. The .csv was opening just fine, but the xls were having trouble. We tried re-installing Microsoft Office and were incredibly close to just blowing the whole machine away and starting from scratch. That was until we decided to check that temp folder’s contents. We had been checking the permissions, but we’d never actually bothered to nose around in there.
There was something critical in this setup that we’d never really thought about. Those 3 XLS files were named the same thing. Now normally this wouldn’t be a big deal, as Windows just tends to increment in the same sort of fashion: filename(x).filetype where x is the increment, and usually this increment continues to infinity in all normal circumstances.
Outlook is a bit different with its temp folder though. Unbeknownst to us, Outlook stops that increment at 100 and errors out if you try to pass it. So you would get to filename(99).filetype and it would stop (as the original doesn’t come with the (x) increment).
This explains why the user experienced the problem about a month and a half later. 3 Files, 5 Times a Week, 7 Weeks and you have about 105 files. In fact knowing that, I could probably guess that it stopped working Thursday of that 7th week.
What I did wrong here was never actually treating the initial cause. Instead of trying to figure out why Outlook had given up on trying to save things to its default user profile temp folder, I accepted the band-aid. I had treated the symptom (the initial error message) and not gone looking for a cause.
Just a goofy little error, but it taught me a big lesson about how I approach error messages in general.