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.
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.
*** Bug 101640 has been marked as a duplicate of this bug. ***
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)?
(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?
(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.
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.
(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.
(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.
(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.
(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)
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.
update keywords
Changing status: NEEDINFO -> NEW Adding keyword 'needsDevEval' [ninjaedit]
(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.
(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.
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
Ok, then I guess it can be bibisected. Adding bibisectRequest
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.
*** Bug 105057 has been marked as a duplicate of this bug. ***
*** Bug 115347 has been marked as a duplicate of this bug. ***
*** Bug 118494 has been marked as a duplicate of this bug. ***
*** Bug 119301 has been marked as a duplicate of this bug. ***
*** Bug 126423 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is 5 or higher
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
*** Bug 129558 has been marked as a duplicate of this bug. ***
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.
(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).
Patch at https://gerrit.libreoffice.org/c/core/+/90082
(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.
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.
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.
*** Bug 131945 has been marked as a duplicate of this bug. ***
*** Bug 136871 has been marked as a duplicate of this bug. ***
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.)
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.
Created attachment 165747 [details] Screenshot
(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.
(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)
*** Bug 139752 has been marked as a duplicate of this bug. ***
(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
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
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
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.
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.
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.
*** Bug 161660 has been marked as a duplicate of this bug. ***