[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] refile Sometimes totally Shreds a Message

From: Mike O'Dell
Subject: Re: [Nmh-workers] refile Sometimes totally Shreds a Message
Date: Mon, 14 Feb 2005 16:22:25 -0500
User-agent: Mozilla Thunderbird 1.0RC1 (Macintosh/20041201)

i've never seen the behavior you describe since adopting
MH back in 1982 or so. at least in The Good Ol' Days,
the refile operation was done with a link-unlink syscall pair and
there is essentially no way for that to impact the contents
of a file.

in fact, i doubt seriously that the contents of the file
matters one whit as to whether this happens.

you didn't mention which version of FreeBSD you were running
or whether you might have the ~/Mail directory mounted via NFS.
i know there is considerable angst over filesystem weirdness
in the 5.x branch of FreeBSD (hence my server running 4.works
for the last several years).

the 0xFFs sound suspiciously like the block erasure that's
done when file blocks are freed, usually when the link
count goes to zero.

if i were guessing (which I am), it sounds like there's a race
condition between the link and unlink and the inode ref count
getting updated incorrectly, thereby triggering an erasure.
i believe that all the blocks are cleaned before the blocks
are released back to the freelists. i haven't looked at the
code in a long time, but given the new locking code in 5.x,
it's not impossible to imagine that getting hosed and produce
the result you are seeing.

again i'm speculating, but you are running 5.x, you may have
found a way to provoke a bug with some regularity,
if not precisely reproduce it. in that case, i suggest you
raise the issue on the 5.x kernel list.


Martin McCormick wrote:
        I use nmh-1.0.4 in FreeBSD UNIX and have noticed that the
refile function occasionally eats a message.  It moves it from one
folder to another all right, but what ends up in the receiving folder
is a file containing all 0xFF's.

        I have tried to capture a message that triggers this behavior
but it is difficult since most messages do not self-destructand refile corectly.
When one does shred, I can't get it back to experiment with because,
by definition of the problem, it is simply gone.

Martin McCormick WB5AGZ Stillwater, OK OSU Information Technology Division Network Operations Group

Nmh-workers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]