On Sat, 28 Jun 1997, Eric Thomas wrote:
> I'm not sure I understand the problem. If all the files belonging to user
> X  are under  a predictable  subdirectory tree  ('/logs/X' or  whatever),
> charging for  the space  should be  as simple  as calculating  disk space
> usage for this  directory tree. If the  files *have* to be owned  by X in
> order for existing bean counting software to work, you could run a script
> before each  bean counting report  is prepared that does  something along
> the lines of 'chown -R xxx /logs/X/*'.

That assumes non-clever, non-hostile users, which is not the case in an
academic setting :-)  The technical problem in Unix is symlinks: a clever
user could move their /u/username/list-archives directory to another
place and create the symlink /u/username/list-archives -> newplace.
Then, LISTSERV's archive writing would still work but the `chown -R`
would not.  File ownership in Unix can never, never reliably be determined
by its location in the directory hierarchy; the only reliable way is via
via the UID in the inode, which must be set at creation time.

> >The  second item  is that  the SCAN  command doesn't  recurse down  into
> >sub-lists.
>
> I don't  agree that SCAN  or list  management commands in  general should
> recurse automatically  into sub-lists. This  might be useful  in specific
> cases  but  it  is  counter-intuitive  to the  primary  purpose  of  list
> management commands, which is to target a specific list.

Because of our widespread use of sub-lists, *not* having recursion is
counter-intuitive to our users!  How about providing recursion as a
per-command option or sitewide option, e.g.

    SCAN super-list pattern ( ALL

> Note that  you can also provide  locally developed commands for  the unix
> version, using  the same localcmd.file  mechanism. You should be  able to
> convert your /WHOIS command to unix with the same syntax.

I was hoping to avoid creating a local command due to the potential for
ongoing support problems.  (As you like to note, the internal structure of
list files and subscription attributes can change with new leases of
LISTSERV.)  Monday (July 30) is my last day at the University of Florida,
so I want to minimize the amount of local code that the remaining
sysadmins (who aren't familiar with LISTSERV) need to support.

David R Nessl  -- Coordinator, Computer Systems (sysprog/sysadmin)
http://www.nerdc.ufl.edu/~david