Re: Error in FTP_get ( FTPAPI )

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

   Hello Peder,
   This is a side effect of the way I designed FTPAPI.
   I designed it so that there is a lower-level "raw" procedure that
   implements the FTP protocol that you can use directly (with a callback)
   so that you can write any sort of logic you want for what to do with
   the data when you receive it.  For instance, maybe you don't want to
   store it in a file, but would rather put it into a variable in your
   program and use it directly.  Or maybe you'd like to save it to some
   other type of object besides a file.  (User space?  data area?   Send
   it to a web service?  Print it out?)   I wanted it to be as open as
   possible, so you can dream up whatever you like for the logic.
   So FTP_get()'s job is to open/create the file, and then call the
   FTP_getraw() procedure which does the actual download.  But, this
   presents the problem you describe -- since FTP_getraw() is the one that
   does the FTP logic and knows whether the server has the file or not,
   and FTP_getraw() knows nothing about the local file strategy, it can't
   very well decide whether to create or not create the file based on it's
   existence.
   You suggestions for a fix aren't perfect, and here's why:
   1) Your first suggestion would have the side effect of deleting an
   existing file if the file is not found on the server.  For example, if
   replacing an existing file on the client side.... with your logic, if
   the server said "not found" on the server, the client would call
   unlink, and delete the existing file on the client.
   2) It's possible to have directories in FTP that are not readable, but
   if you know the filenames, you can download from them.  Therefore, I do
   not want to require FTP_list() to find the file before FTP_get() can
   retrieve it.  Furthermore, it would have a performance impact to
   require a directory to be transferred before a file download.  On a
   directory with a lot of files in it, the directory size can sometimes
   be larger than the file you're retrieving!
   Naturally, if you want to do an FTP_list() before an FTP_get() you can
   code that in your RPG program that calls FTPAPI.... nothing wrong with
   that!   But, I would not want to do this in the general case of all
   calls to FTP_get()
   Perhaps the best solution is to have the callback routine that
   FTP_get() passes to FTP_getraw() handle the open of the file.  It could
   then decide whether to open/clear/replace/append the file after the
   first block of data is received from the server, but before it's
   written to the server.    Of course, this also has the side effect that
   FTP_get() won't give errors about missing directories, or lack of
   authority, etc until after the transfer has begun, which is also
   probably not ideal.
   I don't know...   is the empty file thing a big problem for you?
   Without completely rearchitecting FTPAPI, it's hard to find a perfect
   solution.

   On 2/12/2014 1:41 AM, Udesen, Peder wrote:

   We have discovered that in case the file does not exist on the remote
   server when doing a FTP_get()
   an empty file is created on the local server.


   This is an extract of the source of FTPAPIR4  version 2.2 but as far as
   I can see the error also exists on version 2.3:


   * open the file to
   retrieve

   c                   eval      wwFD = OpnFile(wwLocal: 'W':
   p_write:

   c                                         p_close:
   peSocket)

   c                   if        wwFD <
   0

   c                   return
   -1

   c
   endif



    * download into the
   file...

   c                   eval      wwRC = FTP_getraw(peSocket:
   peRemote:

   c                                     wwFD:
   p_write)

   c                   if        wwRC <
   0

   c                   callp
   CloseMe(wwFD)

   c                   return
   -1

   c
   endif



    * we're done...
   woohoo

   c                   callp
   CloseMe(wwFD)

   c                   return
   0


   The error happens when OpnFile() is called. It creates the empty file
   on the IFS.

   When FTP_getraw() is called it fails causing the local file to be
   closed but not deleted.


   It could be fixed in two ways:

   1)      UNLINK() the file on the IFS before issuing the return -1.

   2)      Doing a FTP_LIST() with the remote file name as an path
   argument and then
   testing if the actual number of array elements is greater than 0.
   This method may be rather ineffective.


   Kind regards

   Peder Udesen

   ***********************************************************************
   *********
   This email and any files transmitted with it may be confidential and
   intended solely for the use of the individual or entity to which they
   are addressed. If you have received this email in error please notify
   the sender.
   ***********************************************************************
   *********


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
[1]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

References

   1. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------