Bug 166890 - recent documents list: when a file doesn't exist, it shouldn't be listed any more
Summary: recent documents list: when a file doesn't exist, it shouldn't be listed any...
Status: RESOLVED DUPLICATE of bug 101302
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.0.0 alpha0+
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-07 08:36 UTC by peter josvai
Modified: 2025-06-07 08:42 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description peter josvai 2025-06-07 08:36:21 UTC
Hi, 


Imagine renaming a directory which has 10 documents that you're working on.

This means that your "recent documents" list will consist of items that only produce a warning pop-up: the file doesn't exist.

This could be fixed.

Once a document turns out not to exist, 
it should be removed from that list.

ALso, if the folder in which the document (which couldn't be opened) would have been doesn't exist, either, then all files in the Recent Documents list could be removed. All automatically.

- - - -
NOTE
- - - -

A possible problem that can easily occur:

If a drive isn't mounted and a document cannot be opened because of that, 
the Recent Document list can be erased.. which is not good.

I have no idea how to handle this :)


I still submit this enhancement suggestion :) 
This is as far as I got :) 



* * * * * thank you for developing Libreoffice and WRITER :) * * * *
Comment 1 Mike Kaganski 2025-06-07 08:42:40 UTC
Marking this as duplicate of bug 101302, even though I see which version it is for. Here is why:

Bug 101302 asked exactly the same. And there was a lengthy discussion there, which established, that it is too expensive to check files' availability; e.g., files on network shares may take seconds to be checked (each); and files on unavailable shares may have to wait for a 30s-60s timeout. This would slow down the startup. An asynchronous check could be made; but then, removal of items that are only temporarily unavailable (on removable media) would be wrong.

The end result is introduction of controls allowing to manually remove the unavailable elements.

*** This bug has been marked as a duplicate of bug 101302 ***