Should non-existant files in a recently used files list be deleted without user prompt?

Question

Say, you have this common thing of "recently used files" or "frequently used files" in your application.

It may easily happen the user moves or deletes a file they had opened recently/frequently. So what happens, now, if the user clicks on that file in your recently/frequently used list…?

1. They should obviously get some feedback/notice that the file is not there anymore.
2. Now, here, is the question: Should the application also automatically delete the file that it could not found from the list?

Arguments

Some ideas I have about this:

• (+) Pro: The entry is absolutely useless, as a user can never open such a file anymore, anyway. It takes valuable space away if it stays there.
• (–) Contra: In some cases a file can only be temporary deleted. While on Android this may e.g. never be the case, this can happen with network shares (think of FTP or samba or so) or so on desktop systems. In such a case the user may just be offline and a file can be opened later anyway.
  On the other hand, an application can blacklist these things. (from looking at the file path)
• (+) Prompt: A user could also be prompted whether the file should be deleted. However, if the file is really gone, this may really not be useful in any way, as it's just another click and possibly obvious?
  • (-) Contra prompt: Confirmation prompts are usually not considered the best UX pattern, so actually an "undo" feature would make sense here. But how can this be accomplished in this case without totally confusing the user? (note we also need to do 1. to notify the user about the fact that the file could not be found…)
• (-) Only manual deletion: We could also not automate that at all, and only let the user click on an "x" or so next to each entry, so they can delete it manually. However, IMHO this is quite lame as – while the feature may independently be useful/needed anyway – in the case when the file is gone, we can totally be clever as an application and at least offer the user to automatically delete it. Why should users first interpret our error message, think and then appropriately react by manually deleting the (correct) entry? (I guess this is "hard" and I doubt many users would even do so, which again could "accumulate" "broken" entries in our list.)

Answer 1

If the user tries to access a file from a recently used list and the file is not found, the item should be removed from the list. The user has obviously been notified the file is not present. They shouldn't have to go through this process again. If they find the file again and open it, then it will go back on the list.

One way to think of it is that only an opened file goes on the list. If the file is closed and then opened again some time later, by accessing the list item, then at the time it's selected, it's immediately removed from the list. Note that it's removed from whatever position it's in at that time - it may not be first anymore. And if it's successfully opened then it gets added back on the top of the list.

This will help maintain the list properly. Files that get accessed are removed immediately and if they can't actually be opened, then it doesn't even go back on the list.

If on the other hand you left an inaccessible file in n'th place on the list - that's the same effect as if it never was attempted to be opened (not the case) and if you moved it to the top of the list that would imply it was opened successfully (also not the case).