有时批量检测不到 FTP 服务器响应答案

【问题标题】：FTP server responses are sometimes undetected in batch有时批量检测不到 FTP 服务器响应
【发布时间】：2012-03-30 17:12:48
【问题描述】：

我在 Win2003 中运行一个批处理文件通过 FTP 传输文件。

批处理文件将 FTP 会话结果通过管道传输到 FIND 以查看是否有 226 成功消息，这很好用。不幸的是，即使文件传输成功并且返回了 226 消息，我也遇到了错误级别的情况。

FTP -s:go.ftp 2>NUL | Find "226 Transfer OK" > NUL
If ErrorLevel 1 Echo ERROR - FTP transfer failed. >> err.log

用户帐户是管理员帐户，因此不是权限问题。有什么想法吗？

更新：

没有通过重定向捕获 226 消息，因此 FIND 失败。在我的测试中，当从调度程序运行时，我将 FTP 输出重定向到一个单独的文件。尽管 FTP 命令运行成功，但没有出现任何服务器响应。

这是我的 FTP 脚本：

open ftpsite
username
password
dir
quit

这是输出 (FTP -s:go.ftp >ftp.log 2>ftp.err)。

User (ftpsite:(none)): open ftpsite
04-01-12  02:35PM       <DIR>          DIR1

04-01-12  02:35PM       <DIR>          DIR2

04-01-12  02:35PM       <DIR>          DIR3

04-01-12  02:35PM       <DIR>          DIR4



dir 
quit

此外，错误流 ( 2>ftp.err ) 中不会出现任何内容。至少我现在知道为什么我的 FIND 的错误级别没有被触发，但是为什么 FTP 服务器的响应没有被捕获？我没有使用 -v 开关或切换详细信息。

【问题讨论】：

-d 启用调试怎么样？您可能需要以其他方式解析ftp.log 以确定它是否成功。
-d 不会产生服务器响应。这就像调度程序为 shell 创建了一个替代现实，它无法获取所有内容。

标签： batch-file ftp piping errorlevel

【解决方案1】：

调度器的路径是否包含FTP和FIND的目录？

您能否将FTP 的输出保存到一个临时文件中，并将其通过管道传输到FIND 以进行测试？这样您就可以在事后检查FTP 的输出，看看可能发生了什么。

如何省略重定向（或将输出定向到错误日志文件），以便查看批处理文件的输出以查找可能的错误消息？

【讨论】：

是的，批处理文件在调度程序中成功运行。我还将所有输出通过管道传输到日志文件，调度程序运行与命令行运行的结果是相同的。路径没问题，否则调度程序的运行会爆炸并且文件不会在那里。我在通过 FIND 处理 FTP 结果作为日志时遇到了同样的问题。
所以听起来您是在说FIND 设置不同的 ErrorLevel（退出代码），具体取决于它是交互运行还是通过调度程序运行。这是否准确地总结了问题？
情况似乎如此，尽管“交互式”并没有退出正确的词，因为我没有在命令提示符下输入 FIND。相反，我正在执行包含 FIND 命令的批处理文件。
我需要澄清我之前的一个 cmets。经过进一步测试，当我将 FTP 输出重定向到日志文件时，实际上缺少服务器响应，但列出了 FTP 命令本身的结果。例如，DIR 命令列出文件内容，但没有 226 响应。我将使用 FTP 的输出更新主要问题。

【解决方案2】：

我在一系列原本成功的传输中发现了一个缺失的 226 代码。我的 ftp 命令是从 vbscript 调用的，但在其他方面与您的类似：

ftp -i -n -s:"\path\to\cmdfile.txt" [ftpserver] > "\path\to\stdout.log" 2> "\path\to\stderr.log"

由于 -n 开关和匿名登录，我的命令文件略有不同：

USER anonymous
cd [UploadDirectory]
binary
put [file]
quit

正如您所指出的，STDERR 流似乎总是为空 - 即使连接不成功。在我所有的测试中，我从未见过 STDERR 包含任何信息。但是，STDOUT 包含事务的完整日志：

220 Unauthorized access to this server is prohibited. All actions are logged.
USER anonymous
230-Anonmyous Access
230 Login successful.
cd [UploadDirectory]
250 Directory successfully changed.
binary
200 Switching to Binary mode.
put "[file]"
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
1058.3090.82quit
221 Goodbye.

我没有像您的示例中那样将命令传递给 FIND，而是解析 STDOUT 文件，并且 99% 的时间都在“226 传输完成”上进行匹配。 1% 的时间我只看到

150 Ok to send data
quit

在缺少 226 的情况下，文件已成功传输 (??) 并且看起来完好无损。所有这一切都表明，虽然不像将输出传递到 FIND 那样优雅，但解析 STDOUT 文件应该给你想要的结果。

我能想到的其他一些项目：

大多数调度程序/cron 问题是由路径和权限引起的。 MS Scheduler 包含一个“开始于（文件夹）”选项 - 您是否尝试将其设置为批处理文件目录？此外，您正在为其运行计划作业的用户帐户可能应该被授予对批处理使用的所有文件和文件夹的显式（非继承）权限。如果批处理始终从命令行运行，但在调度程序上失败，则权限问题可能不仅仅是将调度程序用户帐户添加到管理员组。
您的服务器 ftp 日志显示什么？我的 ftp 服务器是 vsftpd (Linux)，我的服务器日志基本上模仿了重定向捕获的 STDOUT 流（带有一些附加信息）。这可能会告诉您传输成功代码是否正在从您的 ftp 服务器传输。
可能不是原因，但请考虑将 /I 开关与 FIND 一起使用以使其不区分大小写
你试过弄乱重定向命令吗？类似于： ftp ... 2>&1 |找到...

【讨论】：

FTP 传输在我的情况下有效。这更像是调度程序创建了一个 STDOUT 不可用的 shell 环境。正如您所指出的，最初我确实将结果传递给 FIND 命令，但在上面的更新中，我还重定向到了一个文件。如您所见，FTP 命令执行成功，但相关的服务器生成的结果代码不知何故丢失了。