Attachment ExtractFile Limitation

Standard
This might not be new to some of you but today it was the first time I had faced this issue. For the past 2 weeks I have been troubleshooting an agent that is crashing the server. This agent uses third party software to convert documents to pdf, it also uses excel to create a metadata sheet, and it uses code from my last posting to extract attachments. We got IBM and the other vendor involved to help narrow down the problem. I took out the excel part, also the third party code, and today after many many many server crashes we found that the embeddedObject.ExtractFile might be the problem. Well not actually the function but the parameter. Now, I knew that there is a filename limit on windows of 255 characters, but what I didn’t know is that apparently the ExtractFile function has that limit but it takes into account the whole path sent to it. So you might have a filename that is only 100 characters long, but have a deep folder hierarchy and that will cause problems. Anyway we are still waiting on IBM to confirm, but seems pretty clear that this is the problem so we will have to make the folder hierarchy shorter and maybe truncate the filenames.

Anybody else ever face this problem?

[Update]
After a bit more debugging it seems that the problem is happening when the Dir(filename, 0) is called. I use this function to test out if a file already exists before extracting it. I also did more testing on the windows limit and it does seem to be on the whole path, oh well one learns things every day. Anyway we have IBM looking into why the Dir function is not returning an error and just crashes the server. I will have to check the filepath length before sending it to the Dir function.

One thought on “Attachment ExtractFile Limitation

Comments are closed.