Domino C API - replacing file objects

Use method 1), but get first the reference of the next item before removing the attachment.

That seems to work: partially...
-please bear in mind that this is my first month using Domino.

I'm using the syslog to monitor what's going on.
This method adds an unwanted feature - the new attachment is appended, and therefore scanned after the orginals have been scanned (nunecessary and cumbersome).
So - if I send an email with N "blacklisted" attachments, the sever logs 2*N attachments being scanned.

The problem is that the received mail has no attachments (it removes the original attachment and the mime part but the new ones are nowhere to be found - even if they were scanned in my while loop...).
When I'm done I call "NSFNoteUpdate(note_hndl, 0)" and it returns NOERROR, so they should be there...

I've tried updating the note once and twice for each attachment (after adding the file and the new mime part), but the result is the same.
Am I missing some UPDATE_xxx flags - or something basic?

I have not done email exits in CAPI, only DatabaseDriver DLLs.
But if you now have problems with the appended attachments, then why do you not do the append of the notification attachments AFTER the end of the attachments scan loop?
To be able to remove the unwanted attachments you have to collect them in the scan loop in some array or pointer list, and at the end of the scan loop you can remove them all and add only one attachments with the notification what you have done.

Good question - I was just being verbose because the new attachments are "missing" from the final email...

I'll probably rewrite the whole loop tomorrow, but this is a rare special case that I don't want to spend too much time on (that's why I called it "an unwanted feature" ;o).

I'm much more concerned about the new attachments not showing up in the final email...

I have not understood what exactly is the problem with the approach 2)
Why is not possible to collect the attachment names to a String.
You get the next chain element and remove the unwanted attachments.
And at the end of the loop you look for that String content and append the appropriate notification to the mail Body item.
Or is it not possible to append text to the Body item at that stage and you have to completely recreate the Body item???

The body item is fine and text can be appended. The problem is that it's not as easy as it sounds.

An attachment in an email note consists of 3 parts.
a) the mime part of the body. Relatively easy to change/remove.
b) the actual message. Easy to change/remove
c) A FILEOBJECT reference to the actual message http://www-12.lotus.com/ldd/doc/tools/c/6.5/api65ref.nsf/852561bd0045e8e785255b3c005a57bb/00e500ad009400ac85255ea0006d7859?OpenDocument followed by the filename. If I want to change the length of the filename I _probably_ have to use OSLockBlock(), OSMemRealloc() and all kinds of stuff. Memory in Domino can only be reallocated when the it was allocated with the MEM_GROWABLE flag so I'd rather not mess with it. And I'm really not sure how it should be done - the program must be cross-platform so I can't just hack it to work for me now.

Using methods 1) and 2) above, I always have to change a) and b). For 1) the normal way would be to delete c) (the FILEOBJECT reference) and create a new one pointing to the new document, whereas the normal way for 2) would be to modify the old one.
-- but when I think about it, I can probably "reallocate the hard way" (create a new FILEOBJECT, copy the relevant fields and delete the old one) - the structure of the email will change but I doubt it matters.

I'll probably try to implement that approach for method 2) today and let you know how it works.

Perhaps I see it easier then it is, but why do you not simply overwrite the $FILE item with null? You can invalidate the attachment anchor and let the attachment inacessible in the document.

Or if you want to save a quarantine copy of the attachment, then call the NSFNoteExtractFile and the NSFNoteDetachFile methods in sequence.

That's what I'm doing...
For method 1) : NSFNoteExtractFile() to get the file, NSFNoteDetachFile() to delete it, NSFDbAllocObject() & NSFItemAppendObject() to add the new notice.
For method 2) : NSFNoteExtractFile() to get the file, NSFDbReallocObject() & NSFdbWriteObject() to replace the file with the new notice.

The only problem is that damn FILEOBJECT (attachment anchor, c)), that points to the physical file ( b) ).
But I'm sure creating a new FILEOBJECT and replacing the attachment (method 2)) is the easiest way to do it - I'm sure it will work.

I'm doing other stuff today but I'll work on this tomorrow - no need to comment until I get the results from that...

I finally got this to work (almost)...

It turns out that I can create a new FILEOBJECT for both methods (it's safer for cross-platform compatibility than reallocating the old FILEOBJECT), so in effect there is no difference between method 1) and 2)...

I used the program "nsf_dump" from the C API samples to see what's going on.

It (probably) explains my problem: "new attachments not showing up in the final email", I think they are not shown because their MIME entry is  after the MIME_PART_EPILOG in the note.
I'll see what happens if I move the MIME_PART_EPILOG to the end of the note on changed emails.

OK
The problem was the MIME_BODY_PART item fields - the ones after MIME_PART_EPILOG cause weird behaviour and give me a 3F:EA error in imap, because "the note is malformed"or something... http://www-10.lotus.com/ldd/r5fixlist.nsf/0/f042f0dca530160785256ca700728e43?OpenDocument

It finally made it work by rewriting the MIME_BODY_PART pointing to the attachment, and moving the MIME_PART_EPILOG to the end of the note.

Zvonko:
Does this deserve a B or C answer rating?

No points required. You can ask for points refund here:
https://www.experts-exchange.com/Community_Support/

And for grading is my recommendation this: Never give C. Better let delete the question before giving C. If you are disappointed by the expert after several requests for clarification, then you can grade B. Otherwise give A as a sort of saying Thank You. The grading is not more and not less a way to say Thank You for the support given by Experts. The Experts are volunteers offering their free time to support others.

Following help page describes my upper grading strategy slightly differently.
That is because the help page is from the EE platform providers:
https://www.experts-exchange.com/help.jsp#hi73

Cheers,
Zvonko

OK - I put in a request for close.

When I had unlimited points I usually gave:
A for answer or valuable hints to correct answer,
B for some help
C when people spent some time on my question and proposed something that "should work", but doesn't

So in my book you would have been B- or C+, but now I don't have many points so I'm cheap...

But merely explaining the problem to someone pushed me towards the correct way to do it - so thanks for that...

That's mostly the solution: trying to explain the problem to somene else.

So we have so far at least three grading strategies: yours, mine and the one from EE ;-)

See you,
Zvonko

I have no objections.