I've found that you not only have to kill off the linkering process that
is running (ps -auxww | grep pop then search for the PID, and kill -9
that process), then what I do is just do a "cat .username.pop > username"
in the /var/spool/mail directory... Then I just rm the .username.pop
file. Hope that helps....
Ricky
On Thu, 21 Dec 2000, Brian Curtis wrote:
> A response to the last thread "need help" reminded me of a question I've
> been meaning to ask...
>
> Is there a quick remedy to fixing a users mailbox when their connection is
> terminated abnormally resulting in a lingering .username.pop lockfile?
>
> Right now I just tell them to wait a short while, and the mailbox will
> unlock itself. However, I'm waiting for the user that says "I need my mail
> immediately!".
>
> I've tried copying the .pop file back to the normal mail spool file and
> deleting the lockfile, but that produced some strange results.
>
> More specifically, I needed to check email from a remote location over a
> dialup to find that someone sent an unwanted 5mb attachment. I terminated
> the remote connection, copied the .pop lockfile back to the spool file,
> deleted the lockfile, used an mua server-side to delete the email w/
> attachment, then used my remote mua to check mail again just to find it was
> downloading the same email w/ attachment that I thought I had removed.
>
> Checking the mail spool directory again, I saw that the .pop lockfile was
> recreated with the original filesize of the mail spool before removing the
> attachment, even though the current spool file was considerably smaller in
> size.
>
> Did I miss a step, did I go about this the wrong way, or should I have never
> even tried this in the first place?
>
> Running Qpopper 3.1.2 via inetd on a RHL 6.1 box.
>
> Thanks,
>
> --
> Brian Curtis
>
>
