Summary: | chrash when runnimng some KDE-progs and startig bleachbit, too | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Axel Krebs <axel.krebs> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Axel Krebs
2012-07-10 15:26:33 UTC
*** This bug has been marked as a duplicate of bug 274741 *** *** This bug has been marked as a duplicate of bug 254741 *** > KDE should think seriously about reliabitity and rock solid progs instead of > pushing "versio mania..." Just don't use bleachbit. They think they are smart and delete files (caches) used by KDE applications. Of course every application crashes if you delete the files it's using. Just google for KDE and bleachbit and you will notice that it's not a good idea. I also recommend to read http://lwn.net/Articles/313679/ @Martin This is not entirely correct (I hate to do this) First off, two things /are/ correct: 1. DON'T USE BLEACHBIT! Do you really want to allow "stuff" to delete "stuff"?? Seriously, you better have a good backup system. Data in /tmp and /run is deleted with the next reboot and everything else is NOT JUNK. Logs are no junk, caches are no junk. If you *know* you won't need that log anymore or *want* to invalidate a cache, that's fine. Do so. Bleachbit does certainly neither know nor want. 2. Also the bleachbit developers apparently don't entirely know what they do - but that's inherent to the task. Now on what's wrong: *Deleting* a file (even a shared data cache!) is "harmless" (well, you just lost random data, but that's it) The kernel keeps the file hooked internally (so if you ever accidentally delete a file and have any application open that has the file handle open, you can still fetch it from /proc - someone should tell Adobe...) and the data behind file handles is not corrupted at all (but of course the memory is now tagged free and at some point sth. will be written there) What bleachbit however does (by certain configuration) is to *override* the inodes and in this case it's like writing directly into random applications memory (that's the point and flaw of SHM) As result the application memory is suddenly corrupt and about anything can happen (usually it crashes) I do not know, if you -or someone else - right and I am wrong.
That would be fine. When thinking about probabilities, the number of
CONTRAS is larger than the number of PROs I just de-install bleachbit to
avoid further questions on y machine.
Is there a a best-practise on how to deal with date 8backup, taking care
of data) and so on?
Maybe some type of expert-system to be _really_ innovative on KDEs
side... one could check for harmful progs on a systems automatically or
ones to endanger KDE installation.
Axel
---
Am 10.07.2012 17:52, schrieb Thomas Lübking :
> https://bugs.kde.org/show_bug.cgi?id=303308
>
> --- Comment #4 from Thomas Lübking <thomas.luebking@gmail.com> ---
> @Martin
> This is not entirely correct (I hate to do this)
>
> First off, two things /are/ correct:
> 1. DON'T USE BLEACHBIT!
>
> Do you really want to allow "stuff" to delete "stuff"??
> Seriously, you better have a good backup system.
>
> Data in /tmp and /run is deleted with the next reboot and everything else is
> NOT JUNK.
> Logs are no junk, caches are no junk.
> If you *know* you won't need that log anymore or *want* to invalidate a cache,
> that's fine. Do so. Bleachbit does certainly neither know nor want.
>
> 2. Also the bleachbit developers apparently don't entirely know what they do -
> but that's inherent to the task.
>
> Now on what's wrong:
> *Deleting* a file (even a shared data cache!) is "harmless" (well, you just
> lost random data, but that's it)
> The kernel keeps the file hooked internally (so if you ever accidentally delete
> a file and have any application open that has the file handle open, you can
> still fetch it from /proc - someone should tell Adobe...) and the data behind
> file handles is not corrupted at all (but of course the memory is now tagged
> free and at some point sth. will be written there)
>
> What bleachbit however does (by certain configuration) is to *override* the
> inodes and in this case it's like writing directly into random applications
> memory (that's the point and flaw of SHM)
>
> As result the application memory is suddenly corrupt and about anything can
> happen (usually it crashes)
>
Bleachbit "endangers" *everything* it didn't care about in its blacklist (afaik kde cache data was added in recent versions but that doesn't make it less harmful - there's more than KDE and Gnome) > Is there a a best-practise on how to deal with date 8backup, taking care of data) and so on? No, but there are ways for every kind of demand: https://wiki.archlinux.org/index.php/Backup > Maybe some type of expert-system to be _really_ innovative on KDEs > side... one could check for harmful progs on a systems automatically or > ones to endanger KDE installation. Yes, please. Let's have virus scanners. /sarcasm Bleachbit is not malware but just "dangerous" - so is dd. And nc can turn your box into a drone. The approach is to not install and run stuff you do not understand - otherwise everything can be harmful, on every operating system - and virus scanners on windows increase their false positives - mostly because the signature amount is meanwhile /that/ large that clashes are unavoidable. PS: you reply to a bugtracker, please don't quote and in case you seek deeper discussion on this topic head over to forum.kde.org |