Further lessons of closed source software

Further lessons of closed source software

Summary: Recently I was on the task of getting some scripts together for handling FTP commands to run several time a day to move files around. Unfortunately, the platform that was already in place is a Windows 2008 R2 server.

SHARE:
TOPICS: Open Source
6

Recently I was on the task of getting some scripts together for handling FTP commands to run several time a day to move files around. Unfortunately, the platform that was already in place is a Windows 2008 R2 server. But, being optimistic we moved forward on the project. After digging around we soon found out that the list of options is slim on solutions for doing FTP transfers from scripts on Windows. There are really no known good solutions that are free that offer extensible scripting abilities. We ended up selecting CuteFTP Professional which was purchased by somebody else a few years back so a license was already owned for the software. I've used the client for CuteFTP in the past so I felt fairly comfortable with this selection. I also thought about installing Perl for Windows and trying to script something in there, which might still be a viable option.

Partway through the project we discovered that CuteFTP Pro's scripting interface has a few quirks. For example, one of the built-in function calls for doing a "remote rename" would end up passing the commands to the FTP server as "DELE" and "CWD" when it should have been doing a "RNFR" and "RNTO" (rename from, rename to). Yes, this is correct, it was doing a delete instead of a rename. In a production scenario, this is not good. And even further, this behaviour was intermittent, meaning sometimes while making the exact same "remote rename" function call, it would do the correct FTP steps with the "RNFR" and "RNTO" commands, and other times run the "DELE" and "CWD" commands. Totally random behaviour from our testing.

Another issue we faced was that sometimes our scripts would totally fail due to some unknown issue with the CuteFTP Pro scripting interface. All of our function calls would fail from our scripts, and CuteFTP Pro's Transfer Engine all of a sudden stopped writing log files (again for some unknown reason) so we were left without a cause or solution yet again. Rebooting the server and re-running our scripts resolved the problem though (yes, I'm scratching my head, too).

The next step was to contact Globalscape but we soon found out that in order to get direct support for the product, we would need to pay for a maintenance contract. And, Globalscape does not support debugging scripts. And in thinking about this, I can understand it somewhat. But on the other hand, they release a product so they should stand behind it. I also made it a point in my message to them that I think I found a bug in their software, but I got a generic response that they do not support scripts, and that was that. Globalscape does host a user forum, which we checked out as well. But, the forum has such little traffic that a majority of questions go unanswered. Not even employees or developers of the software look through the forums (at least not that we can tell). So, where do we go from here? I'm afraid to select another product and increase our timeframe of the project.

Countless times during this project I found myself reciting "if the server had been a GNU/Linux host, we could do this". And that is so true. I've been a big fan of "ncftp" for many many years, which is a wonderful command based FTP client. And, there are a number of tools available to run scripts for ncftp. A few are "ncftpget","ncftpput", "ncftpbatch", and others that provide a complete toolset for handling FTP from scripts. And, I know the support audience for ncftp is large enough that we would be able to get help if we needed any. I doubt that would be the case as there is already a wealth of information out there as it is.

The problem here is that proprietary products can have very small audiences, and it seems that the vendor providing the software is so focused on sales that they lack in support. If you search on "ncftp" and scripting, you will find countless posts on users helping other users to write scripts, something you can't get with CuteFTP Professional's forums. Again and as I've mentioned in the past, open source software really opens the collaboration of users with other users, so that support resources are vast and often very helpful. Issues with the software get posted quickly and fixed quickly, and as a result the software is often times very powerful and stable.

Topic: Open Source

Chris Clay

About Chris Clay

After administering Linux and Windows for over 17 years in multiple environments, my focus of this blog is to document my adventures in both operating systems to compare the two against each other. Past and present experiences have shown me that Linux can replace Windows and succeed in a vast variety of environments. Linux has proven itself many times over in the datacentre and is more than capable for the desktop.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • Err, why didn't you use any of the Powershell FTP cmdlets that are out there?

    Windows has one of the best scripting platforms out there built into the OS, and there's lots of support for it too. No need to add any overheads of additional scripting tools and no need to install third party code. Especially as most of the cmdlets out there are open source...
    anonymous
  • Yes, that's nothing to do with the openness or proprietariness of the software and everything to do with you not knowing the capabilities of the product or the ecosystem...
    M
    Simon Bisson and Mary Branscombe
  • Simon Bisson :

    The goal here was to not reinvent the wheel. The tidbits of free functions that are available for visual basic scripts are scattered about. Our only concern is picking a product that will continue to be supported in the years to come, and that handle core FTP functionality, not just pieces of it. We do not have Powershell installed on the system (yet), so that may be looked at later on converting all of our scripts from visual basic to Powershell, which is scope creep. I did take a peek and did not see any free Powershell FTP cmdlets (Microsoft posts information on their website about "NetCmdlets" which is try and buy from a 3rd party). It seems there are a lot of 3rd party packages released for this, which I'm guessing is to make up for the lack of products already built in to Windows.
    Chris_Clay
  • Simon Bisson and Mary Branscombe :

    "Yes, that's nothing to do with the openness or proprietariness of the software and everything to do with you not knowing the capabilities of the product or the ecosystem..."

    My personal belief is that the openness provides better built-in functionality from the start, and does not rely on many 3rd parties trying to take up the slack by releasing their own products. From my perspective, there's a LOT more extra duplication going on, on proprietary platforms such as Windows. There's duplication in open source platforms as well (Linux), but usually one of them wins the battle and the others either join the party or there is some sort of collaboration between the parties. Proprietary parties sometimes collaborate (when one buys the other), but I think that's more rare.
    Chris_Clay
  • You're not prepared to learn the key features and tools on the system and that's somehow the fault of Microsoft not making the OS open source? PowerShell is built in from the start; you're still using Visual Basic. Again, nothing to do with open source or proprietary; just your willingness to learn and use the tools that are built in. Duplication; most people call that choice. 'Proprietary' parties frequently collaborate; it's called an ecosystem. If you take the time to research it, you could find a large and supportive community of PowerShell experts who share their scripts and cmdlets and some excellent free tools; or you could carry on thinking it's somehow to do with the development methodology rather than your approach.

    Mary
    Simon Bisson and Mary Branscombe
  • "You're not prepared to learn the key features and tools on the system and that's somehow the fault of Microsoft not making the OS open source?"

    By choosing to make Windows closed, it severely limits the number of contributions from the public user base for supporting software that runs on the platform. And this, I feel is why GNU/Linux offers a superior platform for not only scripting, but as an application platform as well. Take for example a GNU/Linux system running Fedora where the operating system and all of the libraries included are open source. This leaves the door wide open for public contribution and as a result, you can find a program or script or framework to do just about anything you can imagine. Or as in the case here, FTP functions already written, supported, and available for free. Windows? Well, the supporting libraries are not open and free generally, so to me this is a severe limitation. I guess that's why 3rd parties write their own libraries and again, lots of duplication going on. In GNU/Linux you have the entire list of shared libraries already sitting there waiting to be used, and if the developer wants to open one up and look at it, they are open and free to do so. Using the tools that are already there, and not reinventing the wheel, is the point here.

    "Again, nothing to do with open source or proprietary; just your willingness to learn and use the tools that are built in."

    My focus was the fact that a bump was hit while using one of the built-in technologies. Not that this will stop the project. If we were to look at using Powershell, the scripts may need to be completely re-written and there is also a learning curve for some as well. Unfortunately, there are enough of them to make that a large undertaking. In contrast, on a GNU/Linux system we've had Perl and shell scripting for many many years, and old scripts still run quite happily and there is no need to change the framework. Not to mention that the supporting libraries for Perl greatly outweigh anything else there is, even Powershell.
    Chris_Clay