Version: (using KDE 3.5.10) Installed from: Debian testing/unstable Packages I like to run with "unlimited" history in order to catch errors in long compilations or to refer back to previous debugging output. I also have /tmp as a RAM-based tmpfs for performance. Other people may choose to have a disk-based /tmp on a separate partition (e.g. to avoid RAID or other filesystem access overheads). Unfortunately it's not immediately apparent to the user that konsole's screen history is placed in directory /tmp/kde-$USER and hence that "unlimited" history is likely to fill up that partition. I had assumed that it was stored somewhere in $HOME/.kde and that I could safely keep scrollback history up to the size of my /home partition. It's not even immediately obvious when it happens, due to the fact that konsole (for security) unlinks the history file after creation, so you cannot see what it is that has filled up your temporary directory ! Only lsof will reveal the existence of hundreds of megabytes of deleted but still-opened history files belonging to konsole on the filesystem in question. Please could konsole have a configurable temporary directory for its history buffer, in the same way that other KDE applications do which may require to produce large temporary files (for example k3b). This would allow people requiring unlimited history to set it to e.g. /var/tmp (/var in my case is several Gb in size as against the 256Mb of /tmp), or other location of their choosing such as .kde/cache-$USER instead of .kde/tmp-$USER, or even just somewhere in $HOME. If it's desired to keep things simple for the average user, perhaps this could only be enabled as an option when "unlimited" history is selected ?
KDE4 uses a link in your home .kde to point to /tmp/.
Thanks, I didn't know that. However I would like normal temporary usage to remain in /tmp, only long term persistent ones which can grow unboundedly (like konsole log files) to be movable elsewhere. Debian is changing /tmp to always be a tmpfs as from the next release, which is due in a couple of months.
For konsole-4.14, fedora adopted this patch: http://pkgs.fedoraproject.org/cgit/konsole.git/tree/konsole-4.14.1-history_cache_instead_of_tmp.patch to use KStandardDirs::locateLocal("cache",...) instead of KStandardDirs::locateLocal("tmp",...) Latest konsole-15.04.x code uses QDir::tempPath() , I'm considering using QStandardPaths::CacheLocation
What I came up with: http://pkgs.fedoraproject.org/cgit/konsole5.git/tree/konsole-15.04.0-history_cache_instead_of_tmp.patch
See also: https://git.reviewboard.kde.org/r/123804/
Git commit 8b3a05d6889861a463c0a2a1211a6c03fb083af0 by Rex Dieter. Committed on 14/07/2015 at 19:43. Pushed by rdieter into branch 'master'. Store History in cache instead of tmp Some distros have small /tmp and/or use tmpfs, and large history (esp unlimited scrollback) can potentially fill disk or VM. REVIEW: 123804 M +4 -1 src/History.cpp http://commits.kde.org/konsole/8b3a05d6889861a463c0a2a1211a6c03fb083af0
Git commit a1957e8a8fb6662db4d7095254f9884b6b92229d by Kurt Hindenburg. Committed on 16/08/2015 at 17:32. Pushed by hindenburg into branch 'master'. Allow user to select where the scrollback/history files are written. Currently, when unlimited scrollback is used, the files are stored in /tmp. As noted in the bug report, this can cause issues on some distros. The default is still /tmp but the user can selected to use a location in their $HOME folder (QStandardPaths::CacheLocation). This is somewhat a WIP. Allowing for the changes to take effect immediately appears to be a gigantic mess to get to work. M +2 -0 src/CMakeLists.txt M +18 -2 src/History.cpp M +3 -1 src/HistorySizeWidget.cpp M +6 -0 src/MainWindow.cpp A +42 -0 src/settings/FileLocationSettings.cpp [License: GPL (v2/3)] A +41 -0 src/settings/FileLocationSettings.h [License: GPL (v2/3)] A +166 -0 src/settings/FileLocationSettings.ui M +10 -0 src/settings/konsole.kcfg http://commits.kde.org/konsole/a1957e8a8fb6662db4d7095254f9884b6b92229d
IMHO, please don't call the option "scrollbackUseUsersHomeLocation", that's misleading. I'd suggest (something like): scrollbackUseXDGCacheLocation as being more accurate.