有時FTP服務器的響應有時無法檢測到

我在Win2003中運行批處理文件以通過FTP傳輸文件。有時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

該用戶帳戶是一個管理員帳戶，所以它不是一個權利問題。有任何想法嗎？

UPDATE：

該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的errorlevel沒有被觸發，但爲什麼FTP服務器的響應沒有被捕獲？我沒有使用-v開關或切換冗長。

來源

2012-03-30 Tony

'-d'如何啓用調試？您可能需要以其他方式解析'ftp.log'來確定它是否成功。 – tomlogic 2012-04-10 20:41:00

-d不會生成服務器響應。這就像調度程序爲殼體創建了一個替代現實，它無法抓住所有東西。 – Tony 2012-04-16 16:01:42

調度程序的路徑是否包含FTP和FIND的目錄？

您能否將FTP的輸出保存到臨時文件中，並將其輸出到FIND用於測試目的？這樣，您可以在事後查看FTP的輸出，以查看可能發生的情況。

如何忽略重定向（或將輸出指向錯誤日誌文件），以便您可以查看批處理文件的輸出以查找可能的錯誤消息？

來源

2012-03-30 17:31:08 tomlogic

是的，批處理文件從調度程序成功運行。我還將所有輸出傳送到日誌文件，並且調度程序的運行與命令行運行的結果相同。路徑是可以的，否則調度程序的運行會炸彈，文件不會在那裏。通過FIND，我得到了將FTP結果作爲日誌處理的相同問題。 – Tony 2012-03-31 19:40:41

所以這聽起來像你說'FIND'根據它是交互式運行還是通過調度程序來設置不同的ErrorLevel（退出代碼）。這是否準確地總結了問題？ – tomlogic 2012-04-01 19:23:14

這似乎是這種情況，雖然「交互式」不會退出正確的詞，因爲我沒有在命令提示符下輸入FIND。相反，我執行包含FIND命令的批處理文件。 – Tony 2012-04-02 17:31:55

我在一系列成功的轉換中碰到了這個研究中的單個丟失的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.

相反管道命令找到，因爲在你的例子中，我解析的比賽是在「做的時間stdout文件和99％ 226轉移完成。「; 1％的時間我只看到

150 Ok to send data 
quit

在缺少226的情況下，該文件被成功傳輸（??）並且完好無損。所有這一切都可以說，儘管不像輸出管道那樣優雅，解析STDOUT文件應該會給你想要的結果。

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

大多數調度/ cron的問題由路徑和權限引起的。 MS計劃程序包括一個「開始（文件夾）」選項 - 您是否嘗試將其設置到批處理文件目錄？此外，運行計劃作業的用戶帳戶可能應該在該批處理使用的所有文件和文件夾上被授予顯式（未繼承）權限。如果批處理從命令行始終如一地工作，但在調度程序上失敗，則可能會有更多權限問題，而不僅僅是將調度程序用戶帳戶添加到管理員組。
你的服務器ftp日誌顯示什麼？我的ftp服務器是vsftpd（Linux），我的服務器日誌基本上模仿了重定向捕獲的STDOUT流（帶有一些附加信息）。這可能會告訴你傳輸成功代碼是否從你的ftp服務器傳輸過來。
可能不是原因，但考慮使用/ I開關與FIND使其不區分大小寫
您是否嘗試過使用重定向命令？類似於： ftp ... 2> & 1 |找到...

來源

2012-05-09 17:23:50 rhp997

FTP傳輸適用於我的情況。這更像是調度程序創建了STDOUT不可用的shell環境。正如你所指出的，最初我將結果傳給FIND命令，但在上面的更新中，我也重定向到了一個文件。如您所見，FTP命令執行成功，但相關的服務器生成的結果代碼在某種程度上缺失。 – Tony 2012-05-22 20:51:43

有時FTP服務器的響應有時無法檢測到

回答

相關問題