[kde] My KMail keeps searching something
Hi list, Recently my KMail is very busy. It often becomes very busy and keeps accessing my hard drive, and hence slows down my system. I turn on the kmail debug message in kdebugdialog and launch KMail in Konsole, and I found that during the busy period my KMail is searching something in my folder: kmail(11857) KMSearch::slotSearchFolderResult: TEA found 0 .. A lot messages like above and the folder name is repeating. But I don't even know what it is looking for and why it acts like that. Does anyone have any idea about what happens? Thanks, Franklin ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] My KMail keeps searching something
Sorry, I forgot to mention my KMail's information. I'm using KDE 4.6.5, KMail 1.13.7, from Mageia packages. And I have logged my kmail debug log in a text file. I can send it to you if you want to look at it. Thanks. Franklin 2011/9/24 Franklin Weng frank...@goodhorse.idv.tw: Hi list, Recently my KMail is very busy. It often becomes very busy and keeps accessing my hard drive, and hence slows down my system. I turn on the kmail debug message in kdebugdialog and launch KMail in Konsole, and I found that during the busy period my KMail is searching something in my folder: kmail(11857) KMSearch::slotSearchFolderResult: TEA found 0 .. A lot messages like above and the folder name is repeating. But I don't even know what it is looking for and why it acts like that. Does anyone have any idea about what happens? Thanks, Franklin ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] My KMail keeps searching something
Hi Franklin, On Saturday, 2011-09-24, Franklin Weng wrote: Hi list, Recently my KMail is very busy. It often becomes very busy and keeps accessing my hard drive, and hence slows down my system. I turn on the kmail debug message in kdebugdialog and launch KMail in Konsole, and I found that during the busy period my KMail is searching something in my folder: kmail(11857) KMSearch::slotSearchFolderResult: TEA found 0 .. A lot messages like above and the folder name is repeating. But I don't even know what it is looking for and why it acts like that. Does anyone have any idea about what happens? I have no idea why it is doing that on every startup but settles down after a while of running, but I found that this seems to solve the problem: 1) Stop KMail 2) go to directory $HOME/.kde/share/apps/kmail/search (or $HOME/.kde4 on some distributions) 3) delete the file calles Last Search (seems to be localized/translated) 4) Restart KMail Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] My KMail keeps searching something
Thanks, it seems to work. In my case this condition not only happens when startup, but also during accessing. In my PC at home it happens almost every minute. Thanks for your reply. Franklin 2011/9/24 Kevin Krammer kevin.kram...@gmx.at: Hi Franklin, On Saturday, 2011-09-24, Franklin Weng wrote: Hi list, Recently my KMail is very busy. It often becomes very busy and keeps accessing my hard drive, and hence slows down my system. I turn on the kmail debug message in kdebugdialog and launch KMail in Konsole, and I found that during the busy period my KMail is searching something in my folder: kmail(11857) KMSearch::slotSearchFolderResult: TEA found 0 .. A lot messages like above and the folder name is repeating. But I don't even know what it is looking for and why it acts like that. Does anyone have any idea about what happens? I have no idea why it is doing that on every startup but settles down after a while of running, but I found that this seems to solve the problem: 1) Stop KMail 2) go to directory $HOME/.kde/share/apps/kmail/search (or $HOME/.kde4 on some distributions) 3) delete the file calles Last Search (seems to be localized/translated) 4) Restart KMail Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Dolphin file copy question
On Fri, Sep 23, 2011 at 10:18 AM, James Colby jco...@gmail.com wrote: On Thu, Sep 22, 2011 at 10:49 PM, Duncan 1i5t5.dun...@cox.net wrote: James Colby posted on Thu, 22 Sep 2011 15:03:57 -0400 as excerpted: On Thu, Sep 22, 2011 at 2:30 PM, Nikos Chantziaras rea...@arcor.de wrote: On 09/22/2011 09:23 PM, James Colby wrote: List Members - I am trying to use dolphin to copy a rather large directory (approx. 22 Gb. 2000 files, 500 directories) from my laptop to a server using the fish:// protocol. When I first attempted the copy it ran for a few hours and then died due to a network disconnect. Now when I try to do the copy again, I am getting an error saying that the directory already exists, which is true, as it looks like dolphin created the directory structure first, and then starting copying the files. Does anyone know of a way to resume this copy or is it possible to tell dolphin to just skip files and directories that already exist at the destination? If this is not possible with dolphin does anyone have a suggestion as to a better way to do this copy? Use rsync. It was made for exactly this kind of job. Sounds like we have a consensus. :) I've always been a little intimidated by rsync but I guess now is the time to man up (man rsync) /end bad pun Yet another vote for rsync. Note that once you have ssh setup, as it appears you already do, rsync over ssh is quite easy indeed. My personal usage? I run gentoo on both my 64-bit workstation and my 32- bit-only netbook. Gentoo is of course build-from-source, but since my workstation is 64-bit while my netbook is 32-bit, I can't just build once for both, I have to build separately for each. And the netbook being a netbook, I'm not particularly eager to do my building on it. So I have a 32-bit build-image chroot on my 64-bit machine, setup specifically to handle the building and maintenance for the 32-bit netbook. Originally, I copied the image to USB thumbdrive (while it was plugged into the workstation, of course), booted the thumbdrive on the netbook, then copied from it to the netbook's harddrive so I could native-boot from the netbook's own drive. To that point I had never used ssh before, as I had always had only the single machine, so after getting the netbook installed and running in general, I learned how to setup sshd securely and did so, on the netbook (while still using the thumbdrive to sync between the workstation and the netbook, rsyncing twice per transfer, once to the thumbdrive from the workstation, once from the thumbdrive to the netbook). Then I learned the ssh client side setup and did that on the workstation. It was then only a matter of a couple adjustments to the rsync scripts that had been syncing to and from the thumbdrive, to use direct rsync on the LAN, instead. Learning how to handle ssh for both server and client was *MUCH* harder than learning, then scripting, the rsync solution, first to/from the thumbdrive, then script tweaked only slightly to use direct rsync via ssh between the hosts themselves, instead of the thumbdrive sneakernet. So if you already have ssh setup, one end server, one end client, as it sounds like you do, learning to handle rsync over the existing ssh setup should be no sweat at all, comparatively. FWIW the rsync manpage is a bit of a monster, but most of it is dealing with exclusion file formats, etc, that you can probably do without, at least at first. There are a few command line switches that are useful for handling symlinks if you're dealing with them (as I was), but other than that, it's pretty basic. The one hint that I WILL leave you with is to *ALWAYS* use the --dry-run switch the first time around. In my scripts, I actually made that the default, and then go back and run the command again, adding a LIVE parameter, to actually run it. That way, if you screwed up the command, you can catch the error from the output, before you actually do something stupid like switch the source and destination, or forget to mount the source so it copies an empty dir, or some such. Dry-run first will SEEM to take a lot of time and might SEEM a waste, because of all the drive seeking it does, but in reality it's caching all those files so the system doesn't have to work nearly as hard doing the compares the second time around as the data is already cached, so you'd be spending most of that time that it can now skip the second time around anyway, if you hadn't done the dry run. (Tho you may wish to do subdirs or other chunks of around the same sice as your memory on the source machine, rather than the whole 22 gig at once, unless you have 22+ gig of RAM for it to cache to, of course.) Using dry-run has SAVED MY BACON a few times, when I fat- fingered or fat-neuroned something, so I'd definitely recommend ALWAYS using it first. Far better safe than sorry, as they say. -- Duncan -
Re: [kde] Dolphin file copy question
James Colby posted on Sat, 24 Sep 2011 22:44:08 -0400 as excerpted: Another questions that I can't seem to find the answer to. Is it possible to set up rsync to auto retry on failure? The resume option work great, but I would like rsync to retry after a network failure automatically. The other night my connection dropped out shortly after I started my rsync session and an entire night was wasted, and I would like to avoid that in the future. You're challenging me a bit, too. =:^) My first instinct, and a look at the rsync manpage appears to confirm it, is that at a minimum, retries should be scriptable. Simply stick the call to rsync in a loop that tests whether the exit value was 0/success and then exits, or something else. The manpage lists the exit values and their meaning, and you can check for specific values and behave accordingly. So for instance, exit code 30 (timeout in data send/ receive) and exit code 35 (timeout waiting for daemon connection) look to be likely for network issues, and you can have the scripted loop retry the rsync in those cases, but not for instance with exit code 1 (syntax or usage error), where a verbatim retry is very likely to result in the same exit code 100% of the time. (See also the --timeout and --contimeout options.) I'd suggest verifying the actual error codes you get, and testing for them to decide whether to try again, or not. Of course the above assumes you know enough about shell scripting to be able to manage setting up the loop, etc. If not, I can probably help with that too, but that gets complex enough and the assumption is likely enough to be true to be worth making it, initially. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
