COPYCOMMAND, DELCOMMAND:

  A  first  rudimentary  support for the TempFileName msg-field is
featured by COPYCOMMAND and DELCOMMAND.

  They  both specify AmigaDOS shell commands, that are executed by
umsserver. They are invoked with the following commandline:


  COPYCOMMAND filename msgid umsname resultvar

  this must make a copy of the file indicated <filename> and store
this  copy  somewhere. Then it must SET the global environment var
<resultvar>  to  the name of the stored copy. UMS client programms
reading  the  message  must  be able to read the copy of the file.
<msgid>  is  the  MsgID  of  the  message the file is attached to.
<umsname> is the name of the umsserver.
  COPYCOMMAND might try to reduce harddisk usage e.g. by trying to
use hardlinks instead of physical copies whenever possible.
  COPYCOMMAND is invoked every time a message with TempFileName is
stored  to  the  MB. If COPYCOMMAND returns a result code of 10 or
more,  then  the copy is assumed to have failed and the message is
rejected.


  DELCOMMAND filename msgid umsname

  is  supposed  to  delete  the  indicated  file  <filename>. It's
invoked  whenever  a  message  with attached file is deleted, i.e.
during DeleteMsg() or a cleanup.


  COPYCOMMAND  and  DELCOMMAND  maintain  a  repository  for files
additionally  to  the standard message-base with text-fields. This
repository could be on the same physical filesystem as the MB, but
doesn't need to.
  In analogy to the "$umsmb.<umsname>" environment var for the MB,
the  usage  of  "$umsfiles.<umsname>" is recommended for the files
repository.


  The  most serious contraint in the crude frist approach probably
is  the  need to provide a repository that is directly readable by
all  UMS clients. If attached files are supposed to also work on a
network,  most  likely  a network-wide, uniformly named filesystem
would  be  required,  since COPYCOMMAND and DELCOMMAND only run on
the  server  machine and no special action for reading messages is
offered.