Re: [leafnode-list] Problem with texpire

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Stefan Wiens <s.wi@xxxxxxx> writes:

>   All subdirectories under /var/spool/news whose name is a valid
>   newsgroup name are considered for expiry. The only character that
>   will never show up in a group name is ".". (lost+found is also
>   excluded.)
> 
>   All files whose name is all-digits or ".overview" and which can be
>   accessed via directories whose names could form valid newsgroup
>   names may be affected by expiry.
> 
>   If you have to put something under /var/spool/news that leafnode
>   doesn't know about, give it a name containing ".".

No. /var/spool/news belongs to leafnode and nobody else. Don't store
your data in a directory that does not belong to you.

> Descending the entire spooldir would normally require stat()ing each
> filename, but that would be unacceptable. There has to be some
> optimization. My find(1) manpage mentions an optimization by assuming
> that a directory contains 2 fewer subdirectories than its link count.
> Would this work on all target systems?

It has do. Leafnode is designed to run on Unix-lookalikes. If someone
deviates (CygWin, Geek Gadgets/AmigaOS), he has to provide a proper
emulation layer. 

> A strategy like:
> 
> SPOOLDIR=/var/spool/news ; export SPOOLDIR
> find "$SPOOLDIR"/* -path "$SPOOLDIR/*.*" -prune \
>                 -o -path "$SPOOLDIR/lost+found" -prune \
>                 -o -type d -print -links 2 -prune 
> 
> runs fast here. (GNU find version 4.1)

Yup. That's what my new nntpd draft does as well. It also logs files
that don't belong into groups (core dumps e. g.), they should just be
killed instead).

> What to do with symlinks?

Kill them (unlink). We don't create symlinks ourselves. 

> > In the long run, we'd better close the spool dir anyways. Supporting
> > local-spool and efficient NNTP access at the same time is not a good
> > idea.
> 
> You mean a "storage API"?

Whatever. At the moment, I'd rather think of optimizing the reads from
the spool, thus, I'd force incoming articles to use CRLF line ends and
have dots escaped, so that nntpd can just feed the entire article out
with a simple file copy (read/write on a fixed block size), without
looking for line endings, escaping dots and so on.

> Of course, the tradspool-like directory structure is slow and
> inefficient (at least on ext2fs), but the possibility to easily
> handle it with standard UNIX tools like find(1) and grep(1)
> compensates for it.

I don't think we should touch THAT before 2.0.

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list