Travis <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Jul 2008 17:39:03 -0700:
> I never have a problem using sort by date with Pan (0.132). I do it all > the time. Same here. I know you're on MS, but I'm on (Gentoo/~amd64) Linux, running on reiserfs if it matters. OTOH, I have 8 gigs memory, 2 by dual-core Opteron 290 (2.8 GHz) giving me four cores to run on, and most of the system including pan's working dir on four-spindle kernel/mdp RAID-6, so if it's taking too much time on this machine, something's definitely wrong! I also keep pan in my active session, so it starts with X and KDE, because I have posts of some text groups saved for two years (multi- gigabyte cache, set by hand in the config file), now, and pan takes a bit to reload all them, if the cache is cold anyway. But other than just after a reboot (every few weeks, because I do run every other -rc kernel or so), I very seldom have a cold cache, and when I've just booted and entered X, there's other stuff I can be doing while it continues loading pan anyway, so it's not a problem. Other than when X isn't running at all, I restart pan as soon as I've quit it, thus keeping it and posts in cache. That way it starts nearly instantly. Talking about restarting pan... pan doesn't save state that often if you stay in a single group. It'll save group state every time you change groups, but I'm not sure if it saves global state then or not. I've thus gotten in the habit of switching groups every once in awhile if I'm going thru multiple-hundred-posts, so pan will save the state and I won't lose it all if it/X/kernel crashes for some reason. It doesn't happen very often most of the time, but it was a few years ago when the xorg composite extension was newer and MUCH less stable, and that's when I (re)developed the habit. I'd suggest doing something similar, only restarting pan, immediately after making any config change including setting up your server(s), etc. That's the only way to be sure the change in state is properly written. That way, a crash should /not/ take the server config with it. Only if the entire system crashes, leaving a screwed filesystem that an fsck later corrects, lost&found-ing a file or whatever, should there then be an issue. Oh... one more possibility. 0.132 (and previous) had an nzb related buffer overflow issue that was causing pan to crash in some instances, particularly if its tasks.nzb file was messed up. This is/was a potential security issue as well. A patch was posted and Charles has it in SVN for 0.133 now, but 0.133 hasn't been released yet. If you are running a distribution version, ensure they've updated for that security vuln. If you're compiling from SVN, as mentioned, it's already there as well. If you're compiling from versioned source tarball, consider upgrading to svn or manually apply the patch as linked from bug 535413, here: http://bugzilla.gnome.org/show_bug.cgi?id=535413 It could be that you (OP) ran into that somewhere along the line, triggering a crash that corrupted something else. Ensuring that you are running a patched version should in any case eliminate the nzb related sort of future crash, in addition to the related security vuln. -- 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
