Bug 101302 - Deleted files visible as recent documents in menu and start center
Summary: Deleted files visible as recent documents in menu and start center
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: reviewed:2022 target:7.5.0
Keywords: difficultyMedium, easyHack, skillCpp
: 101640 115347 118494 119301 126423 129558 131945 136871 139752 161660 (view as bug list)
Depends on:
Blocks: Recent-Document-List Start-Center
  Show dependency treegraph
 
Reported: 2016-08-04 16:52 UTC by Thorsten Wagner
Modified: 2024-06-20 06:06 UTC (History)
26 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (199.87 KB, image/png)
2020-09-21 23:14 UTC, Thorsten Wagner
Details
LibreOffice Recents (78.27 KB, image/png)
2022-05-21 10:57 UTC, Prasanth K
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Wagner 2016-08-04 16:52:10 UTC
Deleted or renamed files are shown in recent documents view causing error when opening.

Steps to reproduce:

(1) Open document, e.g. with Writer

(2) Save document as "Test.odf" (preview of "Test.odf is shown in recent documents view correctly)

(3) Exit LO

(4) Rename "Test.odf" to "Test 1.odf"

(5) Open "Test 1.odf", e.g. from Finder ("Test 1.odf" is shown in Writer correctly)

(6) Although "Test.odf" no longer exists preview of "Test 1.odf" and preview of "Test.odf" are shown in recent documents view

Issue exists since LO 5.1.5. Issue is present in LO 5.2 as well as in LO built from current master.
Comment 1 Aron Budea 2016-08-04 21:18:27 UTC
Unfortunately the choice had to be made that either this or the behavior described in bug 89394 remains. Of these two, bug 89394 was the more serious issue.

I'm tempted to set this to WONTFIX, but someone might implement a fix that doesn't cause such a lag with recent documents on (disconnected) network shares. Thus setting to NEW for now. Since it doesn't impact high quality work, adjusting importance to low/trivial.
Comment 2 Maxim Monastirsky 2016-08-30 20:35:43 UTC
*** Bug 101640 has been marked as a duplicate of this bug. ***
Comment 3 Pedro 2016-08-30 21:28:04 UTC
As I mentioned in the bug report tagged as Duplicate of this one: how difficult is it to check local drives that are connected and delete thumbnails for files that don't exist? If the problem is network folders isn't it possible to ignore files starting with \\ (or whatever separates network folders)?
Comment 4 Maxim Monastirsky 2016-08-30 21:51:23 UTC
(In reply to Pedro from comment #3)
> isn't it possible to ignore files starting with \\ (or whatever separates
> network folders)?
Right, this will work under Windows (as long as you don't map it to a drive letter), but what to do under Linux, where network shares are typically mounted into folders in the file systems?
Comment 5 Pedro 2016-08-30 22:59:12 UTC
(In reply to Maxim Monastirsky from comment #4)
> (In reply to Pedro from comment #3)
> > isn't it possible to ignore files starting with \\ (or whatever separates
> > network folders)?
> Right, this will work under Windows (as long as you don't map it to a drive
> letter), but what to do under Linux, where network shares are typically
> mounted into folders in the file systems?

It must be possible to establish some rules (even on Linux) to make this usable.

People with local (offline) office will predominantly work on offline files. 
When people move to online LibreOffice then this won't be a problem (assuming they always have a network connection...)

In any case checking the local (system) drives where typically the tmp folders are located should clean up most of the useless thumbnails.
Comment 6 Yousuf Philips (jay) (retired) 2016-09-01 15:25:06 UTC
I wanted to file this same issue many times. :D

So i think we need to have a two part solution to this problem, if we want to remove the deleted files from the list.

1) When LO starts, it should check through the list of recent documents in the user profile to see which ones are still valid and remove the invalid ones.

2) If a document was valid at startup and deleted during the running of LO, then after the error dialog appears, it should remove the entry from the list.

Some users may not like this behaviour, as a file could be on an external source (e.g. flash drive) that was plugged in to access and then when the external source is no longer plugged in, its entry gets removed from the list. So lets see what UX thinks.

The alternative solution that puts the user in full control is to modify the error dialog to have an option to remove the entry from the list.
Comment 7 Heiko Tietze 2016-09-01 18:54:28 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> ... a file could be on an external source (e.g. flash drive) that was plugged 
> in to access and then when the external source is no longer plugged in, 
> its entry gets removed from the list. So lets see what UX thinks.

We should disable those menu entries; better have the truly deleted files grayed out than not showing files that are only temporarily unavailable.
Comment 8 Maxim Monastirsky 2016-09-01 19:21:28 UTC
(In reply to Pedro from comment #5)
> It must be possible to establish some rules (even on Linux) to make this
> usable.
I don't think so. The only sane way of solving this is to do the check in asynchronous way, i.e. check and add the files to the list in the background, without blocking the UI.

> People with local (offline) office will predominantly work on offline files.
Well, based on the amount of "LO freezes when opening the recent list" reports in bz, it's not that uncommon for offline office users to access files on the network. We can't ignore those users.

> In any case checking the local (system) drives where typically the tmp
> folders are located should clean up most of the useless thumbnails.
In Linux there is no "local" and "non-local" drives, as everything is in a single tree. Even the tmp folder itself might be a network drive.
Comment 9 Maxim Monastirsky 2016-09-01 19:22:06 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> 2) If a document was valid at startup and deleted during the running of LO,
> then after the error dialog appears, it should remove the entry from the
> list.
 
> The alternative solution that puts the user in full control is to modify the
> error dialog to have an option to remove the entry from the list.

Sadly both aren't easy to implement. The error dialog is displayed by the file I/O code, and the start center has no control on it (you can see the same dialog by running from the terminal "soffice /path/to/non-existent-file"). So I guess there is no easy way to make it handle recent docs.

Remove the recent doc after the error is much easier to implement, but then again you'll have some issues. e.g. trying to open password-protected docx (but not odt), then cancelling the password prompt is also considered as open-error internally, but we probably don't want to remove the recent entry just because of that.
Comment 10 Pedro 2016-09-01 22:34:35 UTC
(In reply to Maxim Monastirsky from comment #8)

> > In any case checking the local (system) drives where typically the tmp
> > folders are located should clean up most of the useless thumbnails.
> In Linux there is no "local" and "non-local" drives, as everything is in a
> single tree. Even the tmp folder itself might be a network drive.

Ok. So can this be fixed for the Windows OS at least? Tmp folders and System folders are declared in the system variables and are easy to check. And network folders start with \\ or http(s). If LO ignores these, at least it will get rid of links to deleted local tmp files (such as email attachments)
Comment 11 Heiko Tietze 2016-09-07 14:40:42 UTC
Talked to Tomaz about the issue: He agrees that disabling the entries is the simplest and most effective solution. Even when the dialog would offer an option to remove the list entry the workflow is awkward. Files that cannot be opened should be disabled.

Removing needsUXEval, proposing easyHack. NEEDINFO for the codepointers. But the challenge is that you have to check the accessibility when the menu is being opend (or the start center). And there must be no delay. A non-easy solution could be to check the files in separate threads and update the item state for the opened menu.
Comment 12 jani 2016-09-08 07:39:34 UTC
update keywords
Comment 13 Xisco Faulí 2016-09-27 10:36:11 UTC Comment hidden (obsolete)
Comment 14 Heiko Tietze 2016-09-30 12:11:51 UTC
(In reply to Heiko Tietze from comment #11)
> Talked to Tomaz about the issue: He agrees that disabling the entries is the
> simplest and most effective solution.

Another solution might be to have a context menu entry "clear deleted" (or the like). But that works only for the start center and not in the main menu, of course.
Comment 15 Yousuf Philips (jay) (retired) 2016-10-04 05:03:30 UTC
(In reply to Heiko Tietze from comment #14)
> Another solution might be to have a context menu entry "clear deleted" (or
> the like). But that works only for the start center and not in the main
> menu, of course.

Likely can be added to the 'recent files' split button menu which already has 'clear recent documents' and the main menu similar to the 'clear list' entry.
Comment 16 Pedro 2016-11-12 14:55:01 UTC
Xisco, this IS a regression. It worked as expected (non-acessible files were not shown in the Start Center) in branch 5.0
Please see description in Duplicate bug #101640
Comment 17 Xisco Faulí 2016-11-12 14:59:28 UTC
Ok, then I guess it can be bibisected. Adding bibisectRequest
Comment 18 Aron Budea 2016-11-12 16:01:54 UTC
The commit that fixed bug 89394 and caused this one is known, but that doesn't help, as we don't want the previous behavior back, either. Adjusting keyword to bibisectNotNeeded.

Also, since there's some interest in seeing this issue fixed (or at least partly fixed), raising importance slightly.
Comment 19 Adolfo Jayme Barrientos 2017-01-02 23:40:17 UTC
*** Bug 105057 has been marked as a duplicate of this bug. ***
Comment 20 Heiko Tietze 2018-02-18 08:42:53 UTC
*** Bug 115347 has been marked as a duplicate of this bug. ***
Comment 21 Buovjaga 2018-07-15 13:17:46 UTC
*** Bug 118494 has been marked as a duplicate of this bug. ***
Comment 22 Heiko Tietze 2018-08-21 09:08:19 UTC
*** Bug 119301 has been marked as a duplicate of this bug. ***
Comment 23 Heiko Tietze 2019-07-17 09:11:06 UTC
*** Bug 126423 has been marked as a duplicate of this bug. ***
Comment 24 Xisco Faulí 2019-11-29 12:52:51 UTC Comment hidden (obsolete)
Comment 25 Xisco Faulí 2019-12-02 13:41:54 UTC
Changing priority to 'highest' since this a regression and the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 26 Rizal Muttaqin 2019-12-23 07:33:59 UTC
*** Bug 129558 has been marked as a duplicate of this bug. ***
Comment 27 Mike Kaganski 2020-02-12 06:37:58 UTC
Consider also transient inaccessibility situations, when a local file (say, on a flash drive) is unmounted, and gets removed because of inaccessibility, then gets mounted. It might even happen while start center is open - so what should LO do then? constantly track all drives and all files there?

WONTFIX IMO.
Comment 28 Pedro 2020-02-12 09:40:11 UTC
(In reply to Mike Kaganski from comment #27)
> Consider also transient inaccessibility situations, when a local file (say,
> on a flash drive) is unmounted, and gets removed because of inaccessibility,
> then gets mounted. It might even happen while start center is open - so what
> should LO do then? constantly track all drives and all files there?

Having switched almost permanently to Linux I would say the most relevant fix would be to remove at startup all entries starting with /tmp/ (I'm sure there is a similar path in Windows %usertemp% or something)
This would clean up a bit without requiring to check each file (thus avoiding the network validation) and would get rid of most of temp files (e.g. attachments opened directly from email).
Comment 29 Heiko Tietze 2020-03-06 14:17:12 UTC
Patch at https://gerrit.libreoffice.org/c/core/+/90082
Comment 30 Oliver Brinzing 2020-03-06 17:40:01 UTC
(In reply to Heiko Tietze from comment #29)
> Patch at https://gerrit.libreoffice.org/c/core/+/90082

> Local files that are (temporarily) not accessible are now
> shown with 50% less luminance in the start center

I have a question:
What happens when network storage is addressed via drive letters (e.g. subst)?
In my opinion, such a feature should be configurable.
Comment 31 Hussam Al-Tayeb 2020-03-06 18:05:38 UTC
The real solution in my opinion is to do the following only when clicking on entries in history:

If (location not mounted), show a message "the current network location is not currently available, try to connect to blah blah blah or make sure blah blah blah is attached"
else if "(location mounted)", 
   if (path/to/file/exists && file is readable)
      show the entry thumbnail in bright color;
   else show the entry thumbnail in dark color && offer to remove it when clicked on with a "file is not currently available in blahblah location. would you like to remove it from history?" message.
  
Doing so for all files on starting libreoffice is a waste of resources. MS Office checks file existence only on open attempts.

For the record, native linux recents file acts the same too "/home/hussam/.local/share/recently-used.xbel". glib applications only remove files on failed attempts.
Comment 32 Mike Kaganski 2020-04-06 08:19:29 UTC
See bug 131850 comment 1. Citing myself:

A proper fix would be drawing default *module* thumbnail on opening start center (detected from document extension, or from last used filter, which is available in the entries, i.e. without any actual file access); then retrieve all necessary information (encrypted status, availability (bug 101302), anything else) asynchronously in multiple threads, updating the thumbnails as the data is available.

Multiple threads are needed to avoid blocking other thumbnails when a single document is unavailable. Having several threads would allow the thread handling the unavailable document to wait, while other threads succeeding independently.
Comment 33 Oliver Brinzing 2020-04-07 03:58:47 UTC
*** Bug 131945 has been marked as a duplicate of this bug. ***
Comment 34 Mike Kaganski 2020-09-18 08:18:36 UTC
*** Bug 136871 has been marked as a duplicate of this bug. ***
Comment 35 sdc.blanco 2020-09-19 00:37:08 UTC
Alternatively (or additionally), the task of deleting entries in recent list could be given to the user (who will have more insight into/about their network shares, pen drives, etc.)

See bug 61174, comment 0 (under "3. IDEAL", point a) where it is suggested to have an x next to each item, or I would propose "right-click, delete" to avoid accidents.).

Would satisfy basic need for many users (and save developers from mind-reading about network drives, etc.)
Comment 36 Thorsten Wagner 2020-09-21 23:14:22 UTC
I did not take a look at the code right now, but all files seem to be checked when opening Startcenter. I attached a screenshot showing an encrypted file, which I renamed and opened the renamed one afterwards. The file no longer present is shown by a small icon only.

Would not be the following behaviour enough:

(1) Hide files which are no longer present or not accessible during Startcenter launch (as all files seem to be scanned anyway)

(2) If a network drive became available during the meantime, missing files will be visible on the next Startcenter launch again (closing the whole application is not required, closing and reopening the Startcenter window is enough)

(3) If the number of visible files exceeds the maximum number of files displayed within Startcenter, non accessible or no longer present files will be removed from Startcenter subsequently

(4) Deleting recent files removes accessible as well as non existent or not accessible files from Startcenter too

The implementation will be probably easy and maybe better than the current behaviour.
Comment 37 Thorsten Wagner 2020-09-21 23:14:54 UTC
Created attachment 165747 [details]
Screenshot
Comment 38 Heiko Tietze 2020-09-22 06:58:27 UTC
(In reply to Thorsten Wagner from comment #36)
> I did not take a look at the code right now...

Start-up performance is crucial, and checking files takes long. Thumbnails are generated and painted to allocate the space and to position correctly. We need to split this and have the painting done in thread. The code is used also for the templates dialog.

(In reply to Thorsten Wagner from comment #36)
> (1) Hide files which are no longer present or not accessible during
> Startcenter launch (as all files seem to be scanned anyway)

Please don't hide but disable aka grey-out. We may also use some other state for documents that time-out.
Comment 39 sdc.blanco 2020-09-22 11:30:17 UTC
(In reply to sdc.blanco from comment #35)
> Alternatively (or additionally), the task of deleting entries in recent list
> could be given to the user (who will have more insight into/about their
> network shares, pen drives, etc.)
From at least 6.3.6.2, users can delete entries from the start center, which also deletes them from the "Recent Files" menu list, without need for restarting LO. (i.e., gives reasonable alternative for manually deleting entries)
Comment 40 psidiumcode 2021-05-04 17:55:20 UTC
*** Bug 139752 has been marked as a duplicate of this bug. ***
Comment 41 Mike Kaganski 2022-03-16 07:42:01 UTC
(In reply to Maxim Monastirsky from comment #8)
> The only sane way of solving this is to do the check in
> asynchronous way, i.e. check and add the files to the list in the
> background, without blocking the UI.

(In reply to Mike Kaganski from comment #32)
> A proper fix would be drawing default *module* thumbnail on opening start
> center (detected from document extension, or from last used filter, which is
> available in the entries, i.e. without any actual file access); then
> retrieve all necessary information (encrypted status, availability (bug
> 101302), anything else) asynchronously in multiple threads, updating the
> thumbnails as the data is available.
> 
> Multiple threads are needed to avoid blocking other thumbnails when a single
> document is unavailable. Having several threads would allow the thread
> handling the unavailable document to wait, while other threads succeeding
> independently.

So here is the code pointer.
Currently (after recent changes) thumbnail generation is performed fully in RecentDocsViewItem constructor [1]. It has two cases: where a pre-created thumbnail is present (see line 208), and when it's absent (line 167). The former one currently does not attempt to access files, only using pre-existing thumbnail and file name to draw the element in the start center; the latter tries to access the document trying to detect if the document is protected (at which case, it may be problematic when the file is unreachable - see e.g. bug 144566).

The change should:
1. Change second case to not attempt to access files, drawing default thumbnail without lock to avoid UI blocking;
2. Introduce a thread (one for all, or per-item) to access files asynchronously, detecting (a) file availability, and (b) file encryption/password protection. This should result in unavailable items being re-drawn (either as dimmed, or maybe using some overlay indicating its unavailable status), and protected ones re-drawn with lock - when that data is available. The thread should update the item's maPreview1, and use some method of RecentDocsView [2] to update specific items (note that existing RecentDocsView::Reload is not suitable, since it re-creates all the items). It should be possible to terminate the thread early, when user leaves the recent list (e.g., opens a file or switches to templates view).

I clean the unreasonable "regression" keyword (the statement that it should *not* show inaccessible files is nonsense, and the solution should only be marking elements slowly). Marking it as an interesting easy hack.

[1] https://opengrok.libreoffice.org/xref/core/sfx2/source/control/recentdocsviewitem.cxx?r=1dbed50a#123
[2] https://opengrok.libreoffice.org/xref/core/sfx2/inc/recentdocsview.hxx?r=1dbed50a#60
Comment 42 Prasanth K 2022-05-21 10:57:22 UTC
Created attachment 180278 [details]
LibreOffice Recents

I tested by renaming demo file and deleted renamed file , still issue is exist both the files are visible in recent documents . 


 OS :

    Operating System: Linux Mint 20.3
            Kernel: Linux 5.4.0-91-generic
      Architecture: x86-64



Libre office :
 
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 465c3ad95059f0efa13c8027f7383c4d20a5b2ff
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-IN (en_IN); UI: en-US
Calc: threaded
Comment 43 Prasanth K 2022-05-21 10:57:47 UTC Comment hidden (duplicate, obsolete)
Comment 44 Hossein 2022-06-16 12:54:34 UTC
Re-evaluating the EasyHack in 2022

This issue is still present, and relevant. One who wants to implement this should use the code pointers and implementation suggestions from Mike in comment 41.
Comment 45 Commit Notification 2022-08-31 11:24:24 UTC
oguzbalkaya committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2839b604af94dbd1ee59dc6d47dc2f4c6ebd8dc6

tdf#101302: Add option to clear unavailable files in menu/start center

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 46 steve 2022-09-01 09:46:12 UTC
How is this hightest Importance? Setting to medium.

Verified change in Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 3e544b6938ee509a4f6df4c2e2996d71ce072506
CPU threads: 8; OS: Mac OS X 12.5.1; UI render: default; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

Recent Documents > Clear Unavailable Files clears files no longer existing as expected.

Taking the liberty to set to verified - fixed. Feel free to change, if there is still work to be done for this to be closed.

Thanks for the patch.
Comment 47 Buovjaga 2024-06-20 05:56:16 UTC
*** Bug 161660 has been marked as a duplicate of this bug. ***