AttachmentFileSystem incorrectly deletes attachment from filesystem

As you say, minor.

Just a note - it is easier to implement the FS store behaviour.

I think the comments as to expected behaviour might be useful for potential implementers.

- checking this I see the app request confirmation of user before deleting the attachment - so I think is ok at least in that part.
So, the user is "cancelling" an operation that it was already confirmed.

What I think is kind of annoying is the different behavior between DB store and FS store, but minor as you prioritized.

One could either change the way WAttachment works , or change the way the IAttachmentStore implementor behaves.

I am not sure that it is correct that IAttachmentStore.deleteEntry is being called, when there is still a possibility, that the user may cancel.

The problem with changing WAttachment, is that it might break (or conceivably even, fix) existing implementations.

Depending on the final implementation, I propose adding comments similar to the following to IAttachmentStore:

//Delete logic.
// When an entry is deleted (delete record is clicked), then deleteEntry is called.
// deleteEntry should not physically remove the file from storage, since the user may still click cancel.
// If not all the entries have been deleted, when the okay button is clicked, then save is called.
// the entries which need to be deleted (from physical media) should be removed in save method.
// If all the entries have been deleted (individually using delete record button), when the okay button is clicked, then delete is called.
// If delete (entire attachment) is clicked, then save is NOT called, and only delete is called, and the attachment window is closed. User does not have opportunity to click okay.