Additional parameters for files

[ftputiluser]

For writing binary files on MVS I needed to send some additional commands to the ftp server. The following codes shows an example:

file = ftputil.FTPHost(host, user, password).file("/"+name, "wb",
                                            addcmds=("SITE BLKSIZE=0",
                                                     "SITE RECFMT=FB",
                                                     "SITE LRECL=%d" % length ))

Btw. this example shows a workaround for track # 26 by adding a "/" to the filename.

I applied the following patches to achieve this behaviour:

--- ftputil.py 
+++ ../ftputil-2.2.3/ftputil.py 
@@ -191,7 +191,7 @@
         # be explicit
         return None
 
-    def file(self, path, mode='r', **args):
+    def file(self, path, mode='r'):
         """
         Return an open file(-like) object which is associated with
         this `FTPHost` object.
@@ -220,7 +220,7 @@
             #  raise an `IOError`, not an `OSError`
             raise ftp_error.FTPIOError("remote directory '%s' doesn't exist "
                   "or has insufficient access rights" % effective_dir)
-        host._file._open(effective_file, mode, **args)
+        host._file._open(effective_file, mode)
         if 'w' in mode:
             self.stat_cache.invalidate(effective_path)
         return host._file

--- ftp_file.py 
+++ ../ftputil-2.2.3/ftp_file.py 
@@ -87,15 +87,8 @@
         # the file is closed yet
         self.closed = True
 
-    def _open(self, path, mode, **args):
-        """ Open the remote file with given path name and mode
-            and possibly additional arguments.
-
-            Possible keys for args:
-            addcmds     List of additional ftp-commands to send
-                        before the STOR/RETR command (e.g. to set
-                        file information on mvs)
-        """
+    def _open(self, path, mode):
+        """Open the remote file with given path name and mode."""
         # check mode
         if 'a' in mode:
             raise ftp_error.FTPIOError("append mode not supported")
@@ -108,8 +101,6 @@
         transfer_type = ('A', 'I')[self._bin_mode]
         command = 'TYPE %s' % transfer_type
         ftp_error._try_with_ioerror(self._session.voidcmd, command)
-        for command in args.get("addcmds", []) :
-            ftp_error._try_with_ioerror(self._session.voidcmd, command)
         # make transfer command
         command_type = ('STOR', 'RETR')[self._read_mode]
         command = '%s %s' % (command_type, path)

Hopefully, you like this patch and incorporate it into ftputil.

Regards, Axel

[schwa]

Hi Axel,

thanks a lot for the patch! As I read it, these additional approaches came to my mind:

• Does it any harm if you apply the above commands to all sessions, not only those which are used for creating files? If yes, you could use a session_factory which applies the commands to all sessions (ftplib.FTP-compatible objects).

• If there's a way to ask the server for its "MVS-ness" it may be feasible to add a special case to the file construction code. It's correct that I usually avoid special cases but if it's really a special thing that's nowhere else needed I might add it without creating a dedicated interface.

What do you think?

Stefan

[ftputiluser]

Hi Stefan, the additional parameters that I used in my (real life) example are very file specific and not session specific. They allow me to create files with a fixed record length, which may vary from file to file and is thus a parameter for file creation. So, your proposal in the second bullet point wouldn't help me, as I have to open files on the same host (in the same session?) with different record lengths. So in my oppinion file opening is the right place for the additional commands.

There might be a use for session specific commands, but I don't know one.

Axel

[schwa]

After discussion with Axel I decided to not apply this patch to ftputil because it's rather special though goes through several layers in the ftputil code, thereby cluttering the code.

If anyone has a good reason for re-opening this ticket, please do so.