Summary: | Dolphin doesn't update view when download files or exact zipped files | ||
---|---|---|---|
Product: | [Applications] dolphin | Reporter: | do1234521 |
Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | alem99393, kfm-devel, meven29 |
Priority: | NOR | ||
Version: | 22.12.3 | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
do1234521
2023-08-10 01:20:42 UTC
*** This bug has been marked as a duplicate of bug 387663 *** Can you be specific with the folders and which methods you used to extract the folders (context-menu, ark, other...) ? Is the folder where you extracted the files to or downloaded to were on a network filesystem or a symlink directory ? Can specify the dolphin version Menu > Help > About dolphin ? What is your kernel version, given you are using a distro based on Debian 12 stable, that can be old and newer kernel have improved things on that area. (In reply to Méven Car from comment #2) > Can you be specific with the folders and which methods you used to extract > the folders (context-menu, ark, other...) ? > > Is the folder where you extracted the files to or downloaded to were on a > network filesystem or a symlink directory ? > > Can specify the dolphin version Menu > Help > About dolphin ? > > What is your kernel version, given you are using a distro based on Debian 12 > stable, that can be old and newer kernel have improved things on that area. The files were not shown both when download by Firefox or extracted by ark. The folder was the default ~/下载/ folder which is the default ~/download/ folder in a system with Chinese. And the dolphin version is 22.12.3. The bug did not show again after I upgraded my kernel using latest liquorix linux 6.4 kernel. I thought the bug sometimes happen on the default debian12 6.1.x kernel. Marking as "Workforme" then. Reopen with more details if it happens again. I suspect the inotify watch limit could be reached on your system, since a kernel update fixed the issue. The default value `max_user_watches` was changed in a recent kernel version, I couldn't find the specific one though. This documents this issue: https://watchexec.github.io/docs/inotify-limits.html |