I didn’t see an RFE (Request For Enhancement), feedback, or suggestions forum so I’m posting this request here.
When right-clicking on an entry in the Virus Chest, one of the context menu items is “Delete”. That is a poorly named menu entry. The file and its path are listed in the chest so that’s what the users is being led to believe will get deleted. If they just restored the file from the chest (which does NOT remove its entry from the chest) they obviously don’t want to delete the file they just restored. Once the user selects Delete, yes, the following dialog tells them they are removing the entry from the Virus Chest (rather than deleting the file) but that is belated info. The user should know what the action does before they commit to it.
In the Virus Chest, for the content menu, the “Delete” menu entry should be changed to “Delete from Chest” or “Remove from Chest”. The user will then understand what that action does before doing it.
It is a belt and braces if the Restore somehow failed the last thing you would want to have happened is for the only copy (the one in the chest) to be deleted.
Confirm the file is back in the original location and manually delete from within the chest.
Because I couldn’t be sure a Delete from the chest didn’t meant to delete the actual file (the “chest” may simply be a listing regarding a restriction on the file in its original location to prevent it from loading or being read), I went to the folder where was the file and copied it. Then if deleting from the chest ended up deleting the actual file, I’d still have a copy of the file to replace it. Then I chose Delete on the item in the chest and it was AFTER selecting that action that it showed a dialog saying the item would be deleted from the chest. The item disappeared from the chest but the actual file remained in the folder. So the entry got removed (and the restrictions on that file) from the chest but the actual file survived.
My point was that when showing the file and its path, the “Delete” menu entry would be construed as deleting the file the entry was listing. It isn’t until after the user commits the delete action that they get notified the deletion is merely from the chest’s list (and the restrictions it imposes on the quarantined file). So I didn’t have to restore from the copy of the file that I saved because I couldn’t be sure what Delete did before I committed to it.
While items listed in the Virus Chest may not be physical files stored in some invisible and inaccessible storage area but are instead a list of restrictions enforced on that file wherever it actually exists, users don’t see it that way and how the chest works is not clearly explained. To some users, the quarantined file is in the chest. To other users, they may know or believe that entries here are just pointers to the files and the “chest” is a log of restrictions that are currently enforced on the file. So “Delete” could mean to delete the actual file that is shown in the list or to merely remove the restrictions on the file. It would clarify what the Delete action does if it indicated that it only removed the entry from the chest but not delete the actual file. Obviously a content menu entry couldn’t be so long as to explain the complete action but it could be renamed to indicate that its action is to remove the chest entry, like “Delete from Chest” or “Remove from Chest”. Even those might be vague to some users but “Delete” is even more vague.
There is a following dialog telling the user what the Delete action does but that means the user had to first select a destructive action before being sure what it did.
I agree, the current semantics can be a little confusing and/or misleading. I’d even expand the suggested change to something like “Delete from Chest listing”, to be even clearer.
Perhaps this choice from within the chest could also restore the file involved … does doing it the other way around, using “Restore” first, also clear it from the chest?