This problem began when I first switched to SM 2.0a1, and continues. I have several newsgroup accounts. I start up SM and go into one news server and start to read articles there. After I've read a lot of articles, I try to switch to a different newsgroup, one to which I have been subscribed for a long time. But SM puts up a dialog that says: Confirm Would you like to subscribe to xxx.xxx.xxxxx ? [ OK ] [ Cancel ] (Wouldn't it be better if the choices were "Yes" and "No" ?) If I click OK, it moves that newsgroup to the end of the list of subscribed newsgroups. It will do that for every newsgroup I visit thereafter. I've experienced this so many times that I have learned how to work around it. When I get that "Confirm" prompt, I click "Cancel". The cursor switches to the hourglass, showing that it is busy, and it stays that way until the process exits. The workaround is to immediately exit the process and restart. Then the news accounts all work right again, for a little while. But an hour or two later, it is necessary to repeat this workaround.

Same cause as Bug 387271? Patch to nsNntpIncomingServer.cpp by Bug 387271 is as follows; > - rv = NS_NewLocalFileInputStream(getter_AddRefs(fileStream), mNewsrcFilePath); > + rv = NS_NewLocalFileInputStream(getter_AddRefs(fileStream), mHostInfoFile);

Nelson, do you see this since 387271 was fixed 2007-07-13 ?

The description of bug 387271 doesn't sound at all like this problem. That bug sounds like a failure *every time* that the user attempted to subscribe to new newsgroups. The problem described in this bug only happened after the process had been up and running in continuous use for a long time (hours), and it happened just by simply trying to switch from one already-subscribed newsgroup to another. There was no need to launch the subscriptions pane to experience it. SM used to leak memory like a sieve, and I always figured this bug was due to out-of-memory conditions, although I couldn't prove it. I haven't seen this problem in quite a while now. Maybe it got fixed, or maybe SM just doesn't run out of memory so often any more, but this bug would still recur if SM did run out.

"Number of TCP connections" related issue? What does "netstat" say when problem occurs?

Tony, have you seen or heard of this? I'm thinking this is probably WFM based on comment 3 "I haven't seen this problem in quite a while now."

Nelson, do you still see this? what size is your newsrc file when it happens?

I've a similar problem, it has started from SM 2.0 or 2.0.1 on windows 2000 platform, I've subsribed to 80/90 newsgroups and after a while I noticed that he begun to loose my subscription starting from the first one on the list and every time he removes one or more groups, I re-add them and they go on the bottom of the list but he still loose the ones on the top.

The problem occurs when a line in the .newsrc file exceeds some length limit. The line gets incompletely written. The trailing \n doesn't get written. The next line to get written gets lost because it no longer appears to start after a newline, but unless it is also too long, it has a newline that terminates the line. So, now the file has one fewer line than it should, because two lines have been joined (after the first was truncated). The next time the news client tries to read this file, it is unable to parse this joined line, and so drops at least one group from the list. If the user resubscribes, it gets added to the end of the .newsrc. I've taken steps to mitigate the frquency of this, such as shortening the time that the client will remember old articles, which reduces the number of article numbers that it tries to write on one line.

weird, the code that generates the newsrc line doesn't seem likely to lose the linebreak: mReadSet->Output(getter_Copies(setStr)); if (NS_SUCCEEDED(rv)) { newsrcLine.Append(' '); newsrcLine.Append(setStr); newsrcLine.AppendLiteral(MSG_LINEBREAK); } We use MsgNewBufferedFileOutputStream as the stream we write to, so it would almost have to be culprit. Or, the problem is in input, where we use NS_NewLocalFileInputStream, but I don't think that has a line limit length.

Gianluigi, Nelson, do you still see this problem?

Hi, the problem is solved. Thank you. Regards.

(In reply to Wayne Mery (:wsmwk) from comment #10) > Gianluigi, Nelson, do you still see this problem? thanks Gianluigi. Nelson, if you still see this please update the bug