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: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.5.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectNotNeeded, difficultyInteresting, easyHack, needsDevEval, regression, skillCpp, topicCleanup
: 101640 105057 115347 118494 119301 (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: 2018-08-21 09:08 UTC (History)
16 users (show)

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