keeping ALL my news

bill davidsen davidsen at tmr.com
Mon Apr 9 19:58:23 UTC 2001


In article <002c01c0bf95$9868a100$0501a8c0 at enterprise>,
Patrick Amirian <amirianp at sympatico.ca> wrote:
| 
| yes I will ... I've been considering what you're proposing and I don't like
| this because in a year I'll end up having huge groups and I don't think that
| it's a such a good idea so that's why I want to move them to some other
| group..
| 
| ex:
| company.comp.linux (all the new messages for ... 2 weeks)
| company.comp.linux.old (everything after 2 weeks)
| 
| that's more what I want to do..

  I would strongly consider moving to old.company.comp.linux instead, so
that if you ever want to *easily* do something with all those groups you
can do so. This makes it easy to do many tricky things, and if you use
tradspool organization you can do even more. However, next issue...

  Note that doing this "right" is not quite as simple as it looks, since
just moving to another group of any name doesn't move overview pointers,
and references will break, articles will be unreadable, etc. If you just
want to archive for future use in a fairly manual way, you can, but
moving to new groups is not readily supported.

  Having lots of articles is not a huge issue with most newsreaders,
they just read the last N overview entries. You could use CNFS and
"sequential" setup, and add more drives every time the storage started
to get full. That would let you keep your articles online forever, and
once you stop storing data in a cycbuff it can be archived any way you
like, it's not changing.

  I have no good solution for cancel issues, other than disable cancel.
If you really want to save all articles, save them at POST time.

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


More information about the inn-workers mailing list