[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 --- Comment #8 from Jan Kundrát --- Git commit 4cecef196024ffb31fc6d938ea616d17834c2d6b by Jan Kundrát. Committed on 10/09/2017 at 14:38. Pushed by gerrit into branch 'master'. Do not auto remove direct-opened attachments Previously, Trojita tried to wait for a while and remove the temporary file on disk 10 seconds after the application has been launched. That was a possible race, and worse, some applications attempt to be smart and detect this file removal and somehow handle that. An example is Gwenview which auto-switches to a next file in the directory. Another example is Ark which won't let you extract/preview additional files from the archive once the downloaded file has been removed. It's 2017, and it seems that we can now mostly rely on a system behaving "sanely" and cleaning /tmp automatically. That's probably better than a random ad-hoc timeout of 10 seconds which we used to have in Trojita. Another bonus is that this fixes an interoperability problem with Adobe Reader on Windows. That app complained when the file to be openened was locked by another application -- Trojita in this case. Related: bug 344606 Change-Id: Ic150c6d2976ac1a414a6b34a41008aed104c7098 M +2-5src/Gui/AttachmentView.cpp https://commits.kde.org/trojita/4cecef196024ffb31fc6d938ea616d17834c2d6b -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 --- Comment #7 from Nate Graham --- Ah, you're right. Still, I believe it is good policy to trust the system provide these kinds of services unless they are being provided in a grossly inappropriate or negligent manner. /tmp behavior seems sufficient for most everyone else, and it's not like most pictures sent over email are so huge that storing them in /tmp is likely to fill it up. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 --- Comment #6 from Jan Kundrát --- > In modern systems, /tmp is > just a directory in /, not a tiny mount that's prone to filling up, as was > true in daye of yore. Actually, it's the systemd's default configuration to mount a tmpfs at /tmp. Systemd doesn't specify any size, which means that it's going to use the kernel's default, which is total_RAM * 0.5. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 --- Comment #5 from Nate Graham --- Yes. In fact, software in general across all platforms just dumps stuff in /tmp and lets the system figure out the rest. In modern systems, /tmp is just a directory in /, not a tiny mount that's prone to filling up, as was true in daye of yore. If Gentoo doesn't clean /tmp properly, that's a problem they should solve. As a philosophical matter (in software as well as the rest of life), I believe that we should endeavor to fix problems correctly, in the right place, rather than working around them in a way that can cause other problems elsewhere. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 --- Comment #4 from Jan Kundrát --- > /tmp exists for precisely the reason they are using it: to hold temporary > files. No need to perform manual cleaning. The system takes care of that. This appears to be the root of your argument. As an app developer (I'm actually Trojita's maintainer), I would be very happy to rely on that, but I'm not sure that we're already there today. Is that something that the rest of KDE effectively already relies upon? If so, then the matter is settled. I see that systemd ships with a default of 10 days lifetime for stuff under /tmp; this appears to be preserved on RHEL7 as well. That's good. However, Gentoo decided to patch this away [1] in fall 2015 and as such, they do not clean /tmp at all. [1] https://bugs.gentoo.org/show_bug.cgi?id=490676 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 Nate Graham changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Nate Graham --- > While the file is gone, it doesn't mean that one suddenly loses the > possibility to show its content which is already being shown Only because of the technical implementation detail of main memory, and how the file is cached there, even though its presence in permanent storage is gone. Most users don't and shouldn't need to understand this, and are confused by why something that's been deleted would be still available for viewing. If we step back a bit, your real goal is to be able to view picture attachments from Trojita. Right now you can't do that, because of the way Trojita stores them in /tmp and then immediately deletes them (?) and moves them elsewhere, presumably. You are proposing to change Gwenview to accomodate Trojita's odd behavior. I propose the opposite: that Trojita stop doing this weird redirection and timer-based deletion of files in /tmp. /tmp exists for precisely the reason they are using it: to hold temporary files. No need to perform manual cleaning. The system takes care of that. Please work with the Trojita devs to change the their email client to behave in a more standard manner with regards to /tmp usage. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 Jan Kundrát changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #2 from Jan Kundrát --- (In reply to Nate Graham from comment #1) > What would you rather it do? Continue showing a file that no longer exists? Yes. I tried to explain my reasons and the use case behind this situation. While the file is gone, it doesn't mean that one suddenly loses the possibility to show its content which is already being shown. I'm also fine if some features are disabled -- I can imagine that one won't be able to zoom, for example. However, navigating to a different file is confusing in the scenario I described in my original submission, four and half years ago. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 316981] Gwenview automatically switches to a next file in a directory when the original file gets deleted
https://bugs.kde.org/show_bug.cgi?id=316981 Nate Graham changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WONTFIX CC||pointedst...@zoho.com --- Comment #1 from Nate Graham --- What would you rather it do? Continue showing a file that no longer exists? Not sure that would make sense. -- You are receiving this mail because: You are watching all bug changes.
