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

From: DJ <[email-masked]>
Date: Thu, 01 Oct 1998 08:31:37 -0700

At 08:44 PM 9/30/98 CDT, Bob Luckin wrote:
>Gregory said:-
>> >>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
>
>But from what you say above, you're still only talking about triggering
>executables on the server after uploading to it (and maybe running them on
the
>local machine after you've downloaded from the server, although that is
>outside the issue).  Gregory was asking about the need to run an executable
>on the server after you have pulled a file _from_ it.
>
>Do you really have some processes where you want to connect to an
>FTP server, _pull_ the file from the server to your local node, and then
>execute a binary on the server from which you just pulled the file ?
>
----------------------

Many of our customers use this feature to trigger extended logging
(eg log into a database, send a notification that the file has been
downloaded from the server), or to delete or rename a file after it
has been downloaded.  Also to do realtime tracking to see if a file
has been downloaded.

DJ
www.filedrive.com  The Ultimate FTP Software

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 1 Oct 1998 12:15:03 -0400 (EDT)

On Thu, 1 Oct 1998, DJ wrote:

> Many of our customers use this feature to trigger extended logging (eg
> log into a database, send a notification that the file has been

Given the amount of work involved (that is to say, not much) I guess
adding an after-GET trigger is something people would use.  Why is beyond
me, especially if they want to trigger a delete or rename, since these are
irreversible actions taken with incomplete knowledge of the state of
things.  I still contend this is bad systems design and shouldn't be in
the daemon.  Ah well .. here's the rope, there's the tree ..

-- 

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

---

From: Bob Luckin <[email-masked]>
Date: Thu, 1 Oct 98 11:24:43 CDT

> >execute a binary on the server from which you just pulled the file ?

Well, you can delete and rename files using the relevant commands, without
the need to execute anything on the remote server.  And depending on how
things are set up, notification could perhaps be initiated from the client
end instead of the server.  The same might apply to the tracking as well,
depending on the mechanisms used...  But I'll accept that your clients find
the feature useful.

I think Gregory asked his question originally to see how big the demand
for an "ondownload" equivalent to his proposed "onupload" was.  My guess
is there there may not be enough to warrant his effort to implement it.

Of course, once he has written the code for the "onupload" command, it may
not take a lot of extra effort to add "ondownload" as well.  Assuming the
algorithms are similar much of the code may be calls to the functions
already written for "onupload"...  But since he's the one who is proposing
to implement either or both of these features, I'll certainly leave that
decision to him !

  :-)

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Temporarily sigged out"

---

From: Cameron Lemon <[email-masked]>
Date: Thu, 01 Oct 1998 15:15:56 -0300

I guess I may as well offer my two cents worth on this.  An installation that I
am familiar with, runs a bunch of web servers.  Customers ftp their updated
html pages, etc, to a staging server [drop off point ].  The web servers are
cron'd to grab the new files for a particular site from the staging server.
Checks are performed on the new pages, then are written out to that web servers
doc root.  The problem is that this is a polling model, which is inefficient to
say the least.  If an FTP Daemon existed that could act as an intelligent
relay/proxy system, and perform actions per file or whatever, then the polling
system in place could then be event driven.  I think we can all agree that
benefits are numerous when comparing the two models.  Personally, I don't think
that this functionality belongs in the ftpd either, however if it could be
provided as a build option/module, then I'm all for it.  I would definately use
it though either way it was presented to me.  I can always choose to disable or
not to use it.

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 1 Oct 1998 14:39:39 -0400 (EDT)

Let's kill this thread.  Here's the summary:

- onupload is proposed as a trigger after STOR which runs an external
  program as a specified user, passing it the file name STORed

  This has been a Frequently Requested Feature for some time.  It will
  appear in a future VR patch set.

- virtual-retrieve is proposed as a trigger before RETR which runs an
  external program as a specified user, passing it the name of the file
  desired.  This is like SITE EXEC, except the output pipes to the data
  connection instead of the control connection.

  While never requested openly on the list, I proposed this as it is
  orthagonal to onupload and compliments the current features of the
  daemon.  This will appear in a future VR patch set.

- ondownload is proposed as a trigger after RETR which runs an external
  program as a specified user, passing it the file name RETRieved.

  There is no need for this feature since the same results are obtainable,
  in a more reliable fashion, using existing features of the daemon.  The
  proponents, though, are equally intractable, so this too will appear in
  a future VR patch set.

--

---

From: Bob Luckin <[email-masked]>
Date: Thu, 1 Oct 98 13:40:27 CDT

Cameron said :-
>it though either way it was presented to me.  I can always choose to disable or

I don't think anyone is disputing the usefulness in the scenario you describe.
But (unless I misunderstand your description) you're describing a situation
where the file is uploaded to the server, and then an event is triggered.
Whereas I was asking whether anyone wanted to do this after downloading a
file from the server :-

> > > >execute a binary on the server from which you just pulled the file ?

Nevertheless, your two cents is welcome.  And from what Gregory said in his
last email, it looks likely that he will end up implementing both options,
which should make everyone happy.

Cheers, Bob
-- 
Bob Luckin    [email-masked]