If one adds three entries to attachment window, then saves, then opens the window again, deletes only one entry, then clicks cancel, then the file is removed from the file system (cancel should not remove the file).
The implementation works as expected on AttachmentDBSystem.
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:
// 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.
- 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.
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.