Hide Forgot
Description of problem: If the user searched for a file using the text entry box, names of long-deleted files will appear amongst the options. Version-Release number of selected component (if applicable): 2.29.1-4 How reproducible: Every time. Steps to Reproduce: 1. Click on "Windows" key to go to Activities Overlay mode. 2. Type in the name of a file known to have been deleted from the system. Actual results: It appears in the results. Expected results: Should not appear in the results. As it cannot be opened and edited as it is no longer stored on the file system, it is an irrlevent search result. Probably also a potential security/privacy concern for some people if record is maintained of files they thought were removed. Additional info: I have only tried this with files deleted from GNOME and emptied from the Trash. I have not, for instance, searched for files deleted via rm on the BASH shell.
Basically a complete rewrite of this is scheduled - see: http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding For design notes, so I don't think it's worth worrying about this particular problem for now. (It's very hard to keep track of what files in the recent documents list have been deleted without causing performance problems. Switching to using "Tracker" for searching across the user's files and getting more information about the files in the history should allow - in most cases - us to piggyback off the handling of deletes and renames that it already has.)
Owen, thanks for the pointer to that draft document. It is helpful reading and gives some idea of where you are going. Appreciate it. Having read it, I would only like to raise one issue for your further consideration: the article states that some intentions are to "Limit or restrict exposure to filesystem and organizational hierarchies" and "Avoid elaborate filing schemes" which is fine in most use cases but what implications are them from this for users who are pulling down working copies of file structures from repository systems such as SVN? Such data needs to remain structured. In such cases, hierarchies are needed and we will need to still be able to access and navigate them easily. I guess the whole hierarchy would be classified as "trip" so that it can be easily accessed when users are working on specific parts of it and it would be data with a medium-term life. Just something to bear in mind!