AFAIK, a .DTF can only work where Client Access is installed/licensed. I suppose you could manually delete the upload executable if it’s separate from the download executable (and I’m not sure that they’re separate). That is, if the .DTF (From) capability is installed, then the .DTT (To) capability is also installed.
However, there is some control that is fairly easily accessible through Client Access Navigator that could be useful to you.
Open Navigator and right-click on your system under My Connections. Select ‘Application Administration’. Select the ‘Client Applications’ tab. Expand the Access for Windows item down through Data Transfer and Upload to System.
From there, start making your choices. The green-screen WRKFCNUSG command can also be used, as well as the commands that it uses.
But be aware that this <b>does not</b> protect your system. It only tells some of the Client Access functions not to honor requests. Any other ODBC or JDBC (or any of the various remote database access functions) drivers, etc., that are available to Windows. Linux and most PC operating systems, can still be used.
Protection needs to be through object-level security if you really want control.
There are intermediate degrees of control such as the “function usage” facility above. Exit programs are examples. But any security professional will tell you that object-level security is the way to go if you need to plug the holes in your system.
As for modifying an existing .DTF, I’m not sure if that’s reasonably possible. I’m sure that permissions on the .DTF object could stop any permanent changes, but I suspect that temporary changes will still be possible as well as saving new versions under different names.