2011-01-17 8 views
18

Dies ist ein wenig schwierig.Statuscode von FTPWebRequest.GetResponse() Methode

Ich lade Dateien asynchron auf FTP hoch. Nach dem Hochladen jeder Datei überprüfe ich den Status des Hochladevorgangs für diese Datei. Dies kann mit der StatusCode-Eigenschaft des FtpWebResponse-Objekts für diese Anforderung erfolgen. Das Code-Snippet ist wie unten angegeben.

FileStream fs = File.Open(fileName, FileMode.Open); 

while ((iWork = fs.Read(buf, 0, buf.Length)) > 0) 
    requestStream.Write(buf, 0, iWork); 

requestStream.Close(); 

FtpWebResponse wrRet = ((FtpWebResponse)state.Request.GetResponse()); 

Es gibt etwa 37 StatusCode-Werte gemäß msdn. Mir ist nicht bewusst, welche dieser Statuscodewerte sicherstellen, dass die Datei erfolgreich hochgeladen wird. Einige von ihnen, dass ich in meinem Code verwenden für den Erfolg zu überprüfen sind:

wrRet.StatusCode == FtpStatusCode.CommandOK 
wrRet.StatusCode == FtpStatusCode.ClosingData 
wrRet.StatusCode == FtpStatusCode.ClosingControl 
wrRet.StatusCode == FtpStatusCode.ConnectionClosed 
wrRet.StatusCode == FtpStatusCode.FileActionOK 
wrRet.StatusCode == FtpStatusCode.FileStatus 

Aber ich bin keine Kenntnis von der Ruhe. Ich muss mich über diese Codes sicher sein, da ich aufgrund des Fehlers oder des Erfolgs des Upload-Vorgangs andere abhängige Operationen ausführen muss. Eine falsche Bedingung kann sich auf den verbleibenden Code auswirken. Ein anderer Gedanke, der mir in den Sinn kam, war, den obigen Code einfach in einen try..catch zu setzen und nicht von diesen Statuscodes abhängig zu sein. Damit wäre ich nicht von den Statuscodes abhängig und davon ausgegangen, dass ein Fehler immer auf den Catch-Block gerichtet ist. Bitte lassen Sie mich wissen, ob dies der richtige Weg ist.

+0

Ich hatte meine Probleme mit FTP-Servern. Ich würde mit einer pragmatischen Lösung gehen und einfach überprüfen, ob die Datei, die gerade auf den Server hochgeladen wurde, nach dem Hochladen wieder gefunden wird. Ich weiß, dass es die Frage nicht beantwortet - aber ich kam gerade zu der Schlussfolgerung, dass ich der Antwort der FTP-Server nicht vertrauen konnte – MacGyver

Antwort

6

FtpStatusCode.ConnectionClosed ist 426 das ist Connection closed; transfer aborted so würde ich denken, dass ein Fehler tatsächlich wäre. Alles in der 2XX Bereich sollte im Allgemeinen ein Erfolg sein. Für die FTP-Clients, die ich gebaut habe, ist die eine, die ich nur erinnere für den erfolgreichen Upload 226 - FtpStatusCode.ClosingData

+0

Danke Chris. Aber wie ich oben gesagt habe, habe ich auch auf ClosingData Wert überprüft. Meistens oder fast immer in meiner Entwicklungsumgebung bekomme ich diesen Status. Aber irgendwie in der Produktionsumgebung bekomme ich ein Problem. (Ich lade die Datei erneut hoch, wenn die Statuscodes keiner von ihnen entsprechen, wie in meinem obigen Beitrag erwähnt. Die Datei wird tatsächlich zweimal hochgeladen.) Es wird ein anderer Statuscode abgerufen, der nicht zu dem einen gehört, wie ich oben erwähnt habe , aber immer noch ein Fall von Erfolg. Irgendwelche Ideen dazu? – Nishant

+1

Ich würde empfehlen, die Ablaufverfolgung für System.Net zu aktivieren und zu überprüfen, ob Sie weitere Informationen darüber erhalten können, warum der Upload fehlschlägt. http://blogs.msdn.com/b/dgorti/archive/2005/09/18/471003.aspx –

+0

@Nishant Es gibt viele verschiedene Statuscodes aufgrund der verschiedenen Version von FTP RFC, aber Sie müssen sicher sein, welche Version von FTP verwenden Sie und dann sollten Sie eindeutige FTP-Codes besser verwenden SFTP oder FTPS. –

Verwandte Themen