From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/17285 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: Server resetting article number Date: 21 Sep 1998 11:32:35 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156014 32576 80.91.224.250 (20 Oct 2002 23:20:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:20:14 +0000 (UTC) Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA25867 for ; Mon, 21 Sep 1998 11:33:48 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id KAF24650; Mon, 21 Sep 1998 10:04:44 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 21 Sep 1998 10:33:33 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id KAA24125 for ; Mon, 21 Sep 1998 10:33:16 -0500 (CDT) Original-Received: from pocari-sweat.jprc.com (POCARI-SWEAT.JPRC.COM [207.86.147.217]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA25847 for ; Mon, 21 Sep 1998 11:33:10 -0400 (EDT) Original-Received: (from karl@localhost) by pocari-sweat.jprc.com (8.8.7/8.8.7) id LAA28528; Mon, 21 Sep 1998 11:32:36 -0400 Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: Hrvoje Niksic's message of "21 Sep 1998 17:27:42 +0200" Original-Lines: 9 User-Agent: Gnus/5.6.43 XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:17285 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:17285 Hrvoje Niksic writes: > Can Gnus really suck all that much, once the server decides to reset > the article numbers and begin from 1? This happens when the server > software is reinstalled, for instance. Not when it's re-installed sensibly, no. When server software is installed, or re-installed, you're supposed to give the new software an up-to-date active file. There's no excuse for letting article numbers on any given server host become reset.