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

[TM]

http://bugzilla.gnome.org/show_bug.cgi?id=143385

[TM (junkmail-media)]

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

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

[Daniel Robitaille (robitaille)]

Corrected upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=143385

[Sebastien Bacher (seb128)]

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

[Sebastien Bacher (seb128)]

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

[Carthik Sharma (carthik)]

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

[Vassilis Pandis (pandisv)]

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

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

[Wouter Stomp (wouterstomp-deactivatedaccount)]

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.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

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.

[Lorenzo (lorenzo-delledonne)]

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

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

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

[Lorenzo (lorenzo-delledonne)]

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

[David Siegel (djsiegel-deactivatedaccount)]

Great paper cut.

[johnk (johnk-riceball)]

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

[Marcus Carlson (0-launchpad-mejlamej-nu)]

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

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

[Wouter Stomp (wouterstomp-deactivatedaccount)]

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.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Reassigning to match product of the upstream bug.

[Marcus Carlson (0-launchpad-mejlamej-nu)]

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

[David Siegel (djsiegel-deactivatedaccount)]

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

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

[Sebastien Bacher (seb128)]

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

[Timothy Arceri (t-fridey)]

Changed to correct upstream bug

[Chris Wilson (notgary-deactivatedaccount)]

IS this still an issue with GTK 3?

[Dario Ruellan (druellan)]

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.

[Luke B. (duke7553)]

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