Bug 586155 - Keeps Record of Files Even After Deleted from System
Summary: Keeps Record of Files Even After Deleted from System
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell   
(Show other bugs)
Version: 13
Hardware: All Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-26 22:49 UTC by David Le Sage
Modified: 2010-04-27 22:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-04-27 15:30:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Le Sage 2010-04-26 22:49:04 UTC
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):

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.

Comment 1 Owen Taylor 2010-04-27 15:30:11 UTC
Basically a complete rewrite of this is scheduled - see:


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.)

Comment 2 David Le Sage 2010-04-27 22:44:16 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.