Subject: RE: Trigger of an executable upon file send complete

From: [email-masked]
Date: Wed, 30 Sep 1998 11:27:25 +0900

hi,

a.   The program ('x' enabled) can be a shell script or a compiled binary
b.   Separate triggers depending on whether it succeeded or failed to
send/receive a file.

Will this be available in wu-ftpd or wu-ftpd VR7 as that's what I'm using
now.

errr.... am I asking a lot????

rgds and thks

Victor

[email-masked] on 30/09/98 08:43:10 AM

To:   Thian Leng Victor Tan/IT/SINGAPORE/BFI/BNP, [email-masked]
cc:
Subject:  RE: Trigger of an executable upon file send complete

I'm doing just this - mind you I'm patching the source code to do it.

I'm currently modifying BeroFTPD because it's all ANSI 'C' (which makes
the code a *lot* easier to read) and builds with autoconf - but it can
probably be made to VR patched wu.

What are your requirements?  Same exe?  Exe based on file?  Different
exe depending on sucess or failure of transfer?

> Hi,
>
> does anyone know of how I can assign specific jobs to be executed
> immediately after a file has been successfully (or
> unsuccessfully) sent???
>
> apart from polling for those files which is such a waste of CPU
> cycles......
>
> vic
>
>

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 30 Sep 1998 07:46:23 -0400 (EDT)

> a.   The program ('x' enabled) can be a shell script or a compiled binary

A shell script will never work (except for real, non-guest FTP users who,
on a well-secured site, don't exist).  Programs run by the FTP server will
have the same requirements as the current external programs run by the
server; ls, tar, gzip, etc.  Anyone telling you differently hasn't looked
at the problem or has total disregard for security.

I intend to offer a sample program with 'onupload' when it gets in the VR
patches.  This sample would email notification upon upload of a file.

> b.   Separate triggers depending on whether it succeeded or failed to

Success is 100% detectable.  Failure is sometimes undistiguishable from
success due to the vaugaries of TCP buffering.  Apache solved the problem
at the expense of throughput by disabling Nagle.

I'm also considering a 'virtual-retrieve' hook which runs a program when
the remote user RETRs the named (probably non-existent) file.  The output
of that program would be sent via the data connection rather than via the
control connection (which is SITE EXEC).  Except that the file would not
show in a directory listing, it would be undistiguishable from a regular
file to the remote user.  This feature has never been requested on the
mailing list, but I include it in my VR TODO list because it seems
orthagonal to the 'onupload' feature.

I see no point in running a program after a file has been downloaded from
the server.  Make a case for it, I'm listening.

> Will this be available in wu-ftpd or wu-ftpd VR7 as that's what I'm
> using now.
> 

On the subject: Are you asking a lot and will it make the VR patches

I have the 'onupload' and 'virtual-retrieve' commands in my TODO list for
the VR patches. It's not in VR8 (coming out tomorrow).  To date my
priorities have been, in order:

 - fix bugs introduced by earlier VR patches
 - fix bugs found the the base, currently beta-18, release
 - features for which patches have been submitted either to the mailing
   list or directly to me
 - coolness, either of the feature itself or of the job of coding it
 - vauge requests from the mailing list

Within these last two, I take into consideration (also in order):

 - needed for my sites
 - frequency of requests on the mailing list
 - recently talked about
 - Stan's TODO list

The discussion of this feature has moved it up my priority list.  Until
now it has been pretty low since it's been a vauge, infrequent request (no
patch available).  I cannot commit to it being in VR9 or even VR10, but
it's more likely now than when it was a two year old email asking about
email notification on upload.  (Oh, BTW .. BeroFTPD includes _that_
feature; it can email notification on upload.)

I'm releasing a new set of VR patches twice a month until I get through my
TODO list.  I'm currently about 70% of the way through my TODO list, but
the remaining items tend to be larger problems for which there are no
patches on the mailing list, so I'm probably only about 40% of the way
through the work.  Also, as more features go in, and more people start to
use the VR patches, there's more bugs found and fixed (both in the patches
and in the base release).

On the subject: Will any new feature or bug fix be in the base release

OK, I've donned my flame retardant suit ...

As I see it there are three ways it will make it into the base release.  
The first is that enough people decide a VR-patched WU-FTPD is the version
of choice (in which case, I point to BeroFTPD as a canidate since Bernard
has also included Kent's NEWVIRT features and a number of others) that it
becomes the de-facto release.  Another is that Stan officially steps aside
(or is pushed aside) in favor of some consortium similar to the Apache
group and that entity adopts the VR patches.  Finally, Stan picks up the
features and bug fixes and adds them of his own accord.

Of these, the one least likely to happen is the last.  A snowball has more
chance of surviving in .. well, someplace very hot .. than WU-FTPD does
that Stan will ever again show any interest in it other than defending his
position as the keeper.

For years now, the server has languished under Stan's inattentive and
nearly complete absent 'leadership'.  Attempts have been made to push him
aside in the past.  The clamour and uproar on this list doomed those
attempts; probably because they appeared as one person trying to take
over.  Until the list members .. YOU .. decide to call an end to his
tenure .. or until Stan calls it quits .. the chances are what you see in
the base, beta-18 release are all you'll ever see.  Until that happens the
daemon will continue to exist for a few more years.

With the coming of a new FTP specification, the daemon will cease being
viable and will be consigned to oblivion unless active development begins
anew.  A number of people are actively working on the code (again, I point
to BeroFTPD which has implemented FTPSEC for Kerberos 5).  We don't want
to see the daemon disappear.  But, at least I hope, we've learned from the
past.  While we may continue to move the daemon forward, and often times
communicate privately to avoid unnecessary duplication of our efforts, to
date the consensus of the list has been that Stan's lackluster leadership
is what's wanted.  We've decided to live with that.  Until you decide, as
a group, that a change is due so will you.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195