MAPIEx - problem with a specific email

[JoakimEklund]

Hi! We have a process that is being tested and whilst retrieving an email it fails since the attachment could not be saved to the specified directory. Other emails are being worked without any problems. New emails have been added to test if it's that specific email. We have tried adding a retry attempt with a sleep of up to a total of 90 seconds without success. Has anyone encountered a similiar problem before? Suggestions apprieciated! Best Regards, Joakim

[John__Carter]

Hi Joakim - check there isn't anything strange about that mail or the attachment. For example - Is the attachment really big? Does the name contain any weird characters? Is the destination path available? Can the Save be performed manually? Are there any security messages coming up? Does the mail have multiple attachments? Does the mail have any inline images that appear as attachments?

[JoakimEklund]

Hi John. There is nothing wrong with the attachment or the email from my point of view. It's pretty much identical to the rest of the emails in the inbox, just the content of the attachment is different but that shouldn't have any impact since it's an XML-file. I'm though curious if the location where the attachment is saved could be the issue. Since the directory in question is dealing with a lot of saves and deletions. The file size is small, on disk it's ~4k bytes. The filename does not contain any invalid characters(just A-Z and "".""). The path is vaild since the script performs a check to ensure that the file is indeed in that location. I have manually opened, saved the attachment/email. When manually opening the mail profile with outlook, no security messages are shown. The mail has one single attachment. The email is in plain-text. Best Regards, Joakim

[John__Carter]

Hmm weird. The reason I posed those questions is that I've seen oddball mails/attachments screw things up, but if your mail is seemingly 'normal' then it can't be the problem. Is the destination folder very full, ie could Windows be taking a while to decide that the file name is unique and it can save the file in there? But if it's not that I'm running out of ideas...

[JoakimEklund]

Yes, the mail and the attachments are not the issue. The destination directory is not full at any time, nor is the available space on the disk anywhere near running out. So in the process we store the attachment(s), compile a set of files, send these and then delete every file then rinse and repeat. Could it be that Windows is not able to deal with such intense file management? It performs this actions rather quickly. What's a viable solution in that case? The sleep(of a total of 90 seconds) function in Utility - General does not do the job..

[JoakimEklund]

I got it working. My best guess is that it's not possible to get an attachment and store it in a directory if a file with the same name as the attachment already exists within that directory. The reason why it didn't work initially could be that Windows had not gotten ridden of the existing file before the saving of attachment was attempted.