416940 2020-01-30 09:47:33 +0000 Scrollback limit in megabytes 2024-12-04 10:13:18 +0000 1 1 2 Applications konsole history 19.08.0 Debian stable Linux UNCONFIRMED NOR wishlist --- 0 aspotashev konsole-bugs-null dp nate tcanabrava 0 oldest_to_newest 1906487 0 aspotashev 2020-01-30 09:47:33 +0000 SUMMARY I would like to set scrollback limit to a specific number of megabytes and store it in RAM. The objective is to have a deep enough history stored in RAM, but still limit it to using a reasonable amount of RAM (e.g. up to 2 GB). For my use case I can't use Unlimited scrollback stored on disk for information security reasons. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION konsole Version 19.08.0 1906494 1 tcanabrava 2020-01-30 10:48:45 +0000 We have a patch for Konsole that encrypts the file in disk: https://phabricator.kde.org/D16134 It's not landed, but maybe you can take a look on it to see if you feel it would be a good alternative for what you are describing? 1920113 2 aspotashev 2020-04-04 16:34:54 +0000 (In reply to tcanabrava from comment #1) > We have a patch for Konsole that encrypts the file in disk: > https://phabricator.kde.org/D16134 Yes, this would be a perfect solution for my use case. Thanks! 1943046 3 khindenburg 2020-07-11 19:12:16 +0000 I've abandoned that patch; it would better to use an OS encrypted folder/file/HD 1951006 4 aspotashev 2020-08-15 21:52:27 +0000 (In reply to Kurt Hindenburg from comment #3) > I've abandoned that patch; it would better to use an OS encrypted > folder/file/HD This would be less secure (than a random security key per Konsole tab) because a user typically has access to the encrypted files, therefore the Konsole scrollback can be recovered by an attacker in a case when the encryption key is revealed. 1951007 5 aspotashev 2020-08-15 21:53:09 +0000 > random security key I meant: random encryption [private] key 1951008 6 aspotashev 2020-08-15 21:53:13 +0000 > random security key I meant: random encryption [private] key 2304766 7 khindenburg 2024-03-24 01:04:33 +0000 I would agree that perhaps instead of lines, the user could specify MBs. However, I'm sure if that's possible or how complex that would be. 2378862 8 dp 2024-12-04 07:48:07 +0000 Limit in megabytes is essential to avoid consuming all available disk space. It occurred to me few times during long monitoring sessions where a program started to produce an enormous amount of error logging, filled the disk and the OS crashed. There should not exist any such thing as an "unlimited" file logging. 2378869 9 176339 tcanabrava 2024-12-04 08:49:01 +0000 Created attachment 176339 attachment-520800-0.html This is a nice idea . On Wed, Dec 4, 2024 at 8:48 AM mythsmith <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=416940 > > mythsmith <dp@mythsmith.it> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |dp@mythsmith.it > > --- Comment #8 from mythsmith <dp@mythsmith.it> --- > Limit in megabytes is essential to avoid consuming all available disk > space. It > occurred to me few times during long monitoring sessions where a program > started to produce an enormous amount of error logging, filled the disk > and the > OS crashed. > There should not exist any such thing as an "unlimited" file logging. > > -- > You are receiving this mail because: > You are the assignee for the bug. 2378883 10 dp 2024-12-04 10:13:18 +0000 I would add, history file should always start rolling (or rotating) whenever free space on target dir drops below a threshold (with a hard lower limit of 1MB or so). 176339 2024-12-04 08:49:01 +0000 2024-12-04 08:49:01 +0000 attachment-520800-0.html attachment-520800-0.html text/html 1533 tcanabrava PGRpdiBkaXI9Imx0ciI+VGhpcyBpcyBhIG5pY2UgaWRlYSAuPGJyPjwvZGl2Pjxicj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSBnbWFpbF9xdW90ZV9jb250YWluZXIiPjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBXZWQsIERlYyA0LCAyMDI0IGF0IDg6NDjigK9BTSBteXRoc21p dGggJmx0OzxhIGhyZWY9Im1haWx0bzpidWd6aWxsYV9ub3JlcGx5QGtkZS5vcmciPmJ1Z3ppbGxh X25vcmVwbHlAa2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGEgaHJlZj0i aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lkPTQxNjk0MCIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9idWdzLmtkZS5vcmcvc2hvd19idWcuY2dpP2lk PTQxNjk0MDwvYT48YnI+DQo8YnI+DQpteXRoc21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzpkcEBt eXRoc21pdGguaXQiIHRhcmdldD0iX2JsYW5rIj5kcEBteXRoc21pdGguaXQ8L2E+Jmd0OyBjaGFu Z2VkOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgV2hhdMKgIMKgIHxSZW1vdmVkwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8QWRkZWQ8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBDQ3zCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGEgaHJlZj0ibWFpbHRvOmRwQG15dGhzbWl0aC5pdCIgdGFy Z2V0PSJfYmxhbmsiPmRwQG15dGhzbWl0aC5pdDwvYT48YnI+DQo8YnI+DQotLS0gQ29tbWVudCAj OCBmcm9tIG15dGhzbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRwQG15dGhzbWl0aC5pdCIgdGFy Z2V0PSJfYmxhbmsiPmRwQG15dGhzbWl0aC5pdDwvYT4mZ3Q7IC0tLTxicj4NCkxpbWl0IGluIG1l Z2FieXRlcyBpcyBlc3NlbnRpYWwgdG8gYXZvaWQgY29uc3VtaW5nIGFsbCBhdmFpbGFibGUgZGlz ayBzcGFjZS4gSXQ8YnI+DQpvY2N1cnJlZCB0byBtZSBmZXcgdGltZXMgZHVyaW5nIGxvbmcgbW9u aXRvcmluZyBzZXNzaW9ucyB3aGVyZSBhIHByb2dyYW08YnI+DQpzdGFydGVkIHRvIHByb2R1Y2Ug YW4gZW5vcm1vdXMgYW1vdW50IG9mIGVycm9yIGxvZ2dpbmcsIGZpbGxlZCB0aGUgZGlzayBhbmQg dGhlPGJyPg0KT1MgY3Jhc2hlZC48YnI+DQpUaGVyZSBzaG91bGQgbm90IGV4aXN0IGFueSBzdWNo IHRoaW5nIGFzIGFuICZxdW90O3VubGltaXRlZCZxdW90OyBmaWxlIGxvZ2dpbmcuPGJyPg0KPGJy Pg0KLS0gPGJyPg0KWW91IGFyZSByZWNlaXZpbmcgdGhpcyBtYWlsIGJlY2F1c2U6PGJyPg0KWW91 IGFyZSB0aGUgYXNzaWduZWUgZm9yIHRoZSBidWcuPC9ibG9ja3F1b3RlPjwvZGl2Pg0K