使用 ftplib 时出现 EOFError 和异常

发布于 2024-11-25 19:45:26 字数 622 浏览 0 评论 0原文

我正在考虑使用 ftplib (可能还有 ftputil )来执行一些自动化 FTP文件同步。目前我有几个服务器要对此进行测试,但是,当我与两台服务器进行成功对话时,我会在每个错误回复中收到 EOFError-s 。例如:如果我尝试使用不正确的用户/密码登录,我将得到 530 响应以及所有内容……但我也会得到 EOFError;如果我使用正确的用户/密码登录或尝试执行此操作后的 dir() 等,我不会收到 EOFError 。

它似乎只与错误消息一起出现。我强烈怀疑这可能是由服务器而不是 python 引起的:我在其他地方没有发现任何提及此问题的信息。然而,我对服务器设置几乎没有控制权。

我正在寻求想法:

  • 您知道首先可能导致错误的原因是什么吗?
  • 如果是服务器端的话,能说得更具体一些吗?在我知道它是什么之前,我不知道我是否能够对此做任何事情......
  • 你认为我应该如何处理这个?我想我可以在每次处理异常之前添加一个 except EOFError: pass ,但是如果您有更好/更整洁的想法,我很乐意听到它们。

谢谢!

I'm looking into using ftplib (and possibly ftputil) for doing some automated FTP file syncing. I have a couple of servers to test this against at the moment, but, whilst I'm having a successful conversation with both servers, I get EOFError-s with each error reply. For example: if I try to log in with an incorrect user/pass, I will get the 530 response with everything... but I also get an EOFError; if I login with a correct user/pass or try to dir() after doing so etc., I get no EOFError.

It seems to only appear with error messages. I strongly suspect this may be caused by the servers rather than python: I've not found any mention of this issue elsewhere. I, however, have very little control over the server setup.

I'm asking for ideas:

  • Do you know what could be causing the error in the first place?
  • If it's server-side, could you be more specific? I won't know if I'll be able to do anything about it until I know what it is...
  • How do you think I should handle this? I guess I could add an except EOFError: pass before each time I handle an exception, but if you have better/neater ideas I would love to hear them.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

不必在意 2024-12-02 19:45:26

服务器正在发送 EOF 来告诉您它们已终止连接。

您应该与任何其他断开连接事件一样对待它,除了显然您需要使用 except EOFError 来处理它。

请参阅 http://svn.python 的源代码。 org/view/python/trunk/Lib/ftplib.py?view=markup

# Internal: return one line from the server, stripping CRLF.
# Raise EOFError if the connection is closed
182     def getline(self):
183         line = self.file.readline()
184         if self.debugging > 1:
185             print '*get*', self.sanitize(line)
186         if not line: raise EOFError
187         if line[-2:] == CRLF: line = line[:-2]
188         elif line[-1:] in CRLF: line = line[:-1]
189         return line

仅当连接上的 readline() 返回空行时才会引发 EOFError,注释表明该空行是断开连接事件。

编辑您的评论:

服务器不会发送空行。 readline() 返回直到下一个 \n\r\r\n 或全部的内容以上取决于它的配置方式。在这种情况下,没有任何内容可读取,因为已到达文件末尾。这会导致readline()返回一个空行,但这并不意味着已经读取了一个空行。如果读取了空行,readline() 将返回结束该行的字符(\n\r\n\r)。

如果您在使用 FTPUtil 时没有遇到异常,那是因为它在内部处理了该异常。

The servers are sending EOF to tell you that they've terminated the connection.

You should treat this no differently than any other disconnection event, except that obviously you need to handle it with except EOFError.

See the source, from http://svn.python.org/view/python/trunk/Lib/ftplib.py?view=markup

# Internal: return one line from the server, stripping CRLF.
# Raise EOFError if the connection is closed
182     def getline(self):
183         line = self.file.readline()
184         if self.debugging > 1:
185             print '*get*', self.sanitize(line)
186         if not line: raise EOFError
187         if line[-2:] == CRLF: line = line[:-2]
188         elif line[-1:] in CRLF: line = line[:-1]
189         return line

EOFError is only raised when readline() on the connection returns a blank line, which the comment indicates is a disconnection event.

Edit in re your comment:

The server doesn't send an empty line. readline() returns everything up to the next \n or \r or \r\n or all of the abouve depending on how it's configured. In this case, there is nothing to read because the end of the file has been reached. This causes readline() to return a blank line, it doesn't mean a blank line has been read. If a blank line had been read, readline() would return the character that ended the line (\n or \r or \n\r).

If you don't get the exception when using FTPUtil, that is because it handles it internally.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文