- Run a search.
- Delete one of the search results with Delete or Shift-Delete. The results list will not be updated.
- Try to delete it again - you will get an error message because you already deleted it.
Thank you very much for reporting this. Unfortunately, implementing this feature will bring heavy disk operations to recursive monitoring all search paths. This is incompatible with lightweight approach of pcmanfm. Think of it as of feature of the seacrh, sorry for inconveniences it may cause.
Surely when a file is actually deleted from the search results list (rather than from some other process or window) it wouldn't need that. But I guess it might be more confusing for users if files are removed from the list when they are deleted directly from it, but not when they are deleted another way...
The problem is that search folder is not a real folder but synthetic one and none of files in it belong to it. Therefore there is no simple way to inform search folder some file in it was changed (removed), even use fake notifications will not work because no link between "folder" and file exists. The only way to do that is to monitor all folders where files were found but that is too heavy way as I mentioned before. It is the main reason why all file operations but "Copy" are removed from context menu in search folder. I.e. officially we don't support deletion or movement files from it, and update view after such non-official operations isn't supported as well.