[Pan-users] Re: Is there anything like an undelete file?

[Duncan]

beartooth posted <address@hidden>, excerpted
below,  on Fri, 10 Jun 2005 17:11:31 -0400:

> Sometimes -- like with a new keyboard, or too little coffee -- I just seem
> to keep trying to edit down a post itself, instead of remembering first to
> start my reply to it. Then, of course, when I hit delete, the post itself
> vanishes. <sigh>
> 
> Is there any way to get to such posts while they're still only *marked to*
> delete, and undelete them? Or are they just gone?

Hmm, while not common for me, I had the same problem the other day, so
it's definitely not just you!  <g>

What I've found, due to unfortunate crashes due to bad RAM (now fixed,
with a BIOS update that allowed me to declock it slightly), is that no,
such deletes haven't finished at that point just yet.  However, depending
on the situation, it's possible it might be more work to retrieve them
than it's worth.

Here's the deal.  PAN doesn't update its overview store, writing it back
to disk, until you leave the group, either by switching to another or by
shutting down PAN.  If PAN crashes without having that chance to cleanup
and update the group status to the file on disk, when you restart PAN,
all the messages you deleted or marked read from the group you were in at
the time (since you last switched groups) will again show up in the
overview pane as unread.

Thus, what you have to do is make pan "crash" without a chance to write
the group's tracking info back to disk.  On Linux (and I assume other *ix
systems), this basically comes down to doing a 

kill -9 $(pidof pan)

(Not a kill -15, the default, which allows it to close down in an orderly
manner, giving it time to save its files.  pidof = process ID of; there's
a pidof command, which is what the above invokes with the $(command)
structure.)

You can do this either from an xterm or equivalent (konsole here, gterm,
eterm, whatever), or using a text or graphical process display and
management applet such as top (text/cli) or ksysguard (KDE, there should
be a Gnome equivalent but I don't know what it would be).

There are, however, two complications to this.  First, *ALL* the messages
you've dealt with in that time revert.  If you've gone thru a few hundred
in that single group, it's quite possible that you won't consider it
reasonable to have to deal with them ALL, just to get the one back...
depending of course on just how important that /one/ was...

Two, while the OVERVIEWs (incorrectly aka headers) come back, the posts
themselves have already been deleted from the cache.  If the post hasn't
expired from the news server, it's a simply matter to redownload it. 
However, once it's gone from the news server, if it gets deleted at your
end, it's gone -- well, unless you find it on another news server, anyway.
(Google groups will likely carry the group and have the post, if it's a
public text group, not a binary group.  That's not the same, but if the
message is worth retrieving...)

Finally, note that "terminating with extreme prejudice" any program using
the above kill -9 isn't an operation to be undertaken lightly.  Again, it
does /not/ allow the program to terminate in an orderly fashion, and is
generally used to kill a program that's gone off into a never-never land
and won't respond to ordinary polite system requests to close.  Thus,
there's always a small risk when doing so that it was in the middle of
something very important, writing another file to disk or whatever.  With
PAN, that risk is fairly small, provided you exercise reasonable caution. 
However, it remains a small risk.  If the program is in the middle of
writing to disk when it's terminated, doing so may result in creating an
inconsistent file system status on your disk, and thereby a file system in
need of an fsck or whatever to set things straight.  How severe this may
be -- how much other data might be lost as a result -- depends on the type
of file system you are using -- modern journalled file systems shouldn't
lose much except perhaps the individual file that was being written, and
even that /should/ simply return to a previous intact state.  However,
older file systems such as ext2, or newer journalled systems optimized for
speed over safety (a writeback journal instead of ordered or
data-journalling journal), may be somewhat more damaged.  Again, with
something like PAN, provided you don't interrupt it when you know it's
writing to disk (as possible when it's still downloading at full tilt in
the background), the risk is negligible.  However, don't just decide this
is the way you want to close /all/ your programs from now on, as
eventually, it WILL come back to bite you, possibly pretty hard, if you
use kill -9 irresponsibly.  Like a chainsaw, it's a powerful tool, used
correctly, but it'll do some *NASTY* damage, used incorrectly.  Don't
cause your system to be the one damaged!

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html