6
Vote

Error: The Handle is Invalid

description

I am running the following ftps command in a bat file (leaving out pwd):
 
ftps -h web1 -U ciserver -P ***** -ssl All -sslInvalidServerCertHandling Accept -p g:/cis/StagingCIS_vss_metrosearchonline/working/src/Web/* /web/ -r
 
 
 
The bat file is executed from my continuous integration server. The bat file has been tested to run directly from the "run" command as well as directly from a cmd window. All files are copied successfully. When the continuous build server attempts to run the bat file, however, it only copies the first file in the web folder and then closes the connection with the following error:
 
"Error: The Handle is Invalid"
 
My continuous integration server is CruiseControl.net. The following task is part of cruise control's process to run the bat file (it runs after the build task):
<exec>
<executable>G:\CIS\StagingCIS_vss_metrosearchonline\taskscripts\vss_metrosearchonline_FTPS.bat</executable>
<baseDirectory>G:\CIS\tools\</baseDirectory>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
<successExitCodes>0</successExitCodes>
<description>ftps - File Deployment</description>
</exec>

comments

optimator wrote Aug 26, 2009 at 5:59 PM

I have also confirmed this to be a problem when trying to wrap ftps into MSBUILD using the Exec item. My work around is to create my own custom task utilizing the AlexPilotti.FTPS.Client

wrote Jul 13, 2010 at 4:17 AM

nkataev wrote Jul 13, 2010 at 5:53 AM

I faced with this error when run following code:
        System.Diagnostics.Process process = new Process();

        string args = string.Format("-h {0} -U {1} -P {2} -noCopyrightInfo -ssl Implicit -sslInvalidServerCertHandling Accept -pa \"{3}\" {4}",
                                    serverName,
                                    userName,
                                    userPwd,
                                    fileName,
                                    ftpPath
            );

        ProcessStartInfo startInfo = new ProcessStartInfo(ftpsPath, args);
        startInfo.UseShellExecute = false;
        startInfo.CreateNoWindow = true;

        process.StartInfo = startInfo;

        process.Start();

        process.WaitForExit(1000*300);
in debug mode in Visual Studio. (I have to use .net 1.1 and so call ftps.exe like process)
And there is no error when my project executes.

philjones88 wrote Oct 8, 2010 at 4:07 PM

Hmm same problem executing in a stored proc (SQL Server 2008 R2) using xp_cmdshell.

Anyone got any ideas?

wrote Oct 8, 2010 at 4:08 PM

jonhawkins wrote Oct 28, 2010 at 9:28 AM

The reason, (at least what I have found) is that when .net is called from places like Java it really doesn't like anyone playing with the console. You can write to standard out etc but using window width blows up. As a quick test I downloaded the code and commented out "private static int ConsoleFormatWidth" method and all the places it is used, (not many). The only difference I can see at the moment is that the 0% - 100% bit doesn't work. But it does now work when being called by Java (in TeamCity in my case).

Will work on making a cleaner version soon and provide a patch.

wrote Mar 3, 2011 at 4:53 PM

alexp wrote Mar 3, 2011 at 5:19 PM

I will add a "quiet" switch for batch usage, which should resolve the problem.

BTW the ftps.exe client is meant for general purpose usage.
For specific scenarios the direct use of the library is highly encouraged.

wrote Mar 3, 2011 at 7:25 PM

wrote Oct 20, 2011 at 8:41 AM

AspireAlex wrote Jun 20, 2012 at 3:52 PM

I have the same issue when trying to invoke the ftps.exe from a PowerShell script (with arguments). I get this:
+ CategoryInfo          : NotSpecified: (:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
ERROR: The handle is invalid.

alexp wrote Jun 23, 2012 at 6:35 PM

Hi guys,

some ideas for using AlexFTPS with PowerShell: http://ftps.codeplex.com/discussions/284733

Best,

Alessandro

wrote Feb 21, 2013 at 11:35 PM

cdonner wrote May 27, 2015 at 2:27 PM

I can confirm that this issue still exists - in my case when run in an SSIS script task. It would return -1 and the task failed but did not leave any trace of the reason otherwise.
I can also confirm what jonhawkins said - that rebuilding the client after commenting out all references to the screen width (ConsoleFormatWidth) - fixes it.
ConsoleFormatWidth is obviously not a method as suggested, but it is used by a method and in a few other places to determine the formatting of the output. I didn't refactor this code, just commented it out to get it working. Some things are no longer printed to the console now, but because it runs headless anyway, that's just fine.

wrote May 27, 2015 at 2:32 PM