When gwenview shows a file, the file gets deleted by another application and its parent directory contains other files, gwenview proceeds to another file. I guess this is handy in some situations, but it is very inconvenient with temporary files. Trojita, a Qt IMAP e-mail client which became part of KDE last year, has a feature of directly opening attachments which is implemented via QDesktopServices::openUrl() (which itself uses xdg-open, iirc). KDE's default settings register gwenview for image/jpeg MIME type. Trojita saves the file under a name obtained from the following object: QTemporaryFile(QDir::tempPath() + QLatin1String("/trojita-attachment-XXXXXX-") + fileName->replace(QLatin1Char('/'), QLatin1Char('_'))); This typically results in something similar to /tmp/trojita-attachment-148682-someImage.JPG. In order to prevent leaving endless temporary files on the disk, there's a timer which deletes the saved file after a few seconds. (If there's as better way of doing this, please let me know. I suspect that the data: URL scheme is not a good match for possibly multi-MB files and it would also require explicit support in the launched applications.) The problem is that gwenview apparently listens for FS events about the current file disappearing. If such an event is detected, the viewer switches to the next file in the same directory. This, of course, breaks this feature as long as any of the following criteria are met: - the user opens more images at once (after a few seconds, all viewers will point to a single file) - there are other temporary files from other applications (like rekonq's HTML5 videos) Could you please make sure that this feature is deactivated when the application is called in a way to show a single image? Suggestions for better working with temporary files are appreciated as well. Reproducible: Always
What would you rather it do? Continue showing a file that no longer exists? Not sure that would make sense.
(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.
> 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.
> /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
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.
> 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.
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.
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 -5 src/Gui/AttachmentView.cpp https://commits.kde.org/trojita/4cecef196024ffb31fc6d938ea616d17834c2d6b