Opening a deleted 'recent document' results in a new file.

Bug #8949 reported by TM on 2004-10-10
94
This bug affects 6 people
Affects Status Importance Assigned to Milestone
GNOME Panel
Invalid
Undecided
Unassigned
GTK+
Won't Fix
Wishlist
One Hundred Papercuts
Low
Unassigned
gtk+2.0 (Ubuntu)
Low
Unassigned
TM (junkmail-media) wrote :

Selecting a file to open from the Computer->Recent Documents list results in a
new file of the same type if the file no longer exists. Perhaps a better
default behavior is to tell the user the file doesn't exist or has been moved
and to give the user the option to create a new file of the same type.

Sebastien Bacher (seb128) wrote :

I've reported the bug upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=155091

Sebastien Bacher (seb128) wrote :

*** Bug 13723 has been marked as a duplicate of this bug. ***

Sebastien Bacher (seb128) wrote :

*** Bug 19680 has been marked as a duplicate of this bug. ***

Carthik Sharma (carthik) wrote :

Changing status to confirmed, since there is an active upstream bug about this issue, which has not yet been resolved.

Changed in gnome-panel:
status: Unconfirmed → Confirmed

I'm not overly confident in this patch because I don't know my way around gnome-panel. It fixes the described problem for me though.

Sebastien Bacher (seb128) wrote :

Thanks for your patch, I've commented upstream about it

Changed in gnome-panel:
status: Unconfirmed → Confirmed
Changed in gnome-panel:
assignee: seb128 → desktop-bugs

The creation of a new file doesn't happen anymore with current gutsy, but gnome still tries to open the deleted file with the associated application, which it shouldn't do.

The real solution would be some file monitoring thing, as mentioned in the upstream bug. But a quick fix for the problem at hand would be just to check if the file still exists before launching an application to open it. I think this would not be hard to implement. If the file does not exist anymore simply popup a dialog saying so.

Changed in gnome-panel:
status: Confirmed → Triaged
Lorenzo (lorenzo-delledonne) wrote :

Although a real fix for this issue could easily end in a complex code re-engineering, I think we actually can patch it up in a manner that this bug could be counted as a "Paper Cut" (http://blog.davebsd.com/2009/06/03/paper-cut/):

As TM wrote back in 2004 (!):
* "Perhaps a better default behavior is to tell the user the file doesn't exist or has been moved
and to give the user the option to create a new file of the same type."
* And, in case, remove the entry from the list.

Lorenzo (lorenzo-delledonne) wrote :

Or, we could remove broken entries right _before_ the list shows up.

Then, maybe we should open a new bug for the actual re-engineering. By the way, please consider this upstream [bug/proposed solution]: http://bugzilla.gnome.org/show_bug.cgi?id=548069 where "a_64" suggests we use standard links for tracking the life of each in-list recent file. It seems to be an elegant and easy-to-implement idea, but I haven't got enough understanding of the matter to determine that.

TM (junkmail-media) wrote :

Glad to see some movement on this! Thanks for taking a look.

Lorenzo (lorenzo-delledonne) wrote :

Thank you for the report! ;)
Waiting for folks from "One Hundred Paper Cuts" project confirming this bug and hopefully we'll see this fixed in time for Karmic release!

      Lorenzo

Great paper cut.

Changed in hundredpapercuts:
status: New → Confirmed
Changed in hundredpapercuts:
milestone: none → round-3
Changed in hundredpapercuts:
milestone: round-3 → round-9
johnk (johnk-riceball) wrote :

+1 to suggestion 12. Remove the name from the list, before the list is displayed.

Removing items from the list before it's displayed is not really possible. Think about remote shares that you have not saved the password for, for example. And even if the file is local the file may disappear after you have open the menu (check then act problem). Actually even if we check the file right after you selected it if it exists or not, even then it might be removed before the application has started (yes, I know it's a small chance but it still can happen - eg your doing a large move on a older that hasn't finished....). So maybe the problem is within the application themselves on how they should handle files that doesn't exists? Gedit for instance creates a new file, OOo says the file doesn't exist, Eog somehow says it doesn't exists.

Vish (vish) wrote :

David , this seems to be a bigger task... see comment #17

Changed in hundredpapercuts:
assignee: nobody → David Siegel (djsiegel)

Even with the problems listed in comment 17, just checking local filesystems and removing files from the list which are known not to exist anymore eliminates most of the problem for most home users.

komputes (komputes) on 2009-09-17
description: updated
description: updated
Changed in hundredpapercuts:
milestone: round-9 → lucid-round-10

Reassigning to match product of the upstream bug.

affects: gnome-panel (Ubuntu) → gtk+2.0 (Ubuntu)
Changed in gnome-panel:
importance: Unknown → Undecided
status: Confirmed → New
status: New → Invalid
Vish (vish) on 2010-01-15
Changed in hundredpapercuts:
status: Confirmed → Triaged
Vish (vish) on 2010-02-13
Changed in hundredpapercuts:
importance: Undecided → Low

David, could you comment on what behavior you'd like?

I agree with Wouter (#19). Simply checking for local files before the Recent Documents menu is shown and removing files that aren't found will fix easily 80% of occurrences of this problem.

Ayan George (ayan) wrote :

I'm looking into what it will take to cull deleted files from the list when opened.

Changed in gtk+2.0 (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Ayan George (ayan)
status: Triaged → In Progress
Sebastien Bacher (seb128) wrote :

unsubscribing the review team, the change is not really fixed the issue but rather a workaround to display an error

Vish (vish) on 2010-07-18
Changed in hundredpapercuts:
status: Triaged → In Progress
Changed in gtk:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Ayan George (ayan) on 2011-06-29
Changed in gtk+2.0 (Ubuntu):
assignee: Ayan George (ayan) → nobody
status: In Progress → Confirmed
Changed in hundredpapercuts:
milestone: lucid-round-10 → precise-9-miscellaneous
Timothy Arceri (t-fridey) wrote :

Changed to correct upstream bug

Changed in gtk:
importance: Wishlist → Unknown
status: Confirmed → Unknown
Changed in gtk:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Changed in hundredpapercuts:
milestone: precise-9-miscellaneous → quantal-10-gtk
Changed in hundredpapercuts:
status: In Progress → Confirmed

IS this still an issue with GTK 3?

Changed in hundredpapercuts:
milestone: quantal-10-gtk → raring-misc
importance: Low → Wishlist
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Dario Ruellan (druellan) wrote :

Seems fixed on GTK3, Ubuntu 12.10.

If you delete a file, no longer shows on the "recent document list".
If you delete a file while the file selector dialog is open, the list did not autorefresh (the deleted file is still listed).
If you then open the previously deleted file, the editor (Gedit on my tests) open a blank document, but no file is created unless you save the document.

Changed in hundredpapercuts:
assignee: Paper Cuts Ninja (papercuts-ninja) → nobody
Changed in hundredpapercuts:
importance: Wishlist → Low
Changed in gtk:
status: Confirmed → Won't Fix
Luke B. (duke7553) wrote :

I can confirm this issue no longer affects Ubuntu 18.04, as recently viewed items are removed upon deletion.

Changed in hundredpapercuts:
status: Confirmed → Fix Released
Changed in gtk+2.0 (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.