Hi,
I get the following error if I try to upload/download with a wrong path.
The exception is valid and should be raised. But it would help debugging a lot if the exception would contain the filename.
Why not add the filename to the exception?
If there are good reasons to not add it: Is there a better way than wrapping a lot of FTPHost calls with a try-except-reraise wrapper?
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/host.py", line 499, in download
conditional=False, callback=callback)
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/file_transfer.py", line 182, in copy_file
source_fobj = source_file.fobj()
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/file_transfer.py", line 94, in fobj
return self._host.open(self.name, self.mode)
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/host.py", line 203, in open
encoding=encoding, errors=errors, newline=newline)
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/file.py", line 92, in _open
self._conn = self._session.transfercmd(command)
File "/home/foo_the_d/local/lib/python2.7/site-packages/ftputil/error.py", line 172, in __exit__
raise FTPIOError(*exc_value.args, original_exception=exc_value)
FTPIOError: 550 Failed to open file.
Debugging info: ftputil 3.2, Python 2.7.6 (linux2)
Regards,
Thomas Gütter :-)
PS: I hope you are fine. I hope we meet again somewhere.
Changed the ticket description to use
{{{...}}}
markup for the traceback.
ftputil uses the error message from the server in the exception text. All servers I've seen so far, include the file name in the error message. For example:
Python 3.4.1 (default, Nov 3 2014, 14:38:10) [GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ftputil >>> host = ftputil.FTPHost("localhost", omitted_user, omitted_password) >>> host.stat("walk_test/nonexistent") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/schwa/sd/python/ftputil/ftputil/host.py", line 853, in stat return self._stat._stat(path, _exception_for_missing_path) File "/home/schwa/sd/python/ftputil/ftputil/stat.py", line 735, in _stat _exception_for_missing_path) File "/home/schwa/sd/python/ftputil/ftputil/stat.py", line 689, in __call_with_parser_retry result = method(*args, **kwargs) File "/home/schwa/sd/python/ftputil/ftputil/stat.py", line 656, in _real_stat lstat_result = self._real_lstat(path, _exception_for_missing_path) File "/home/schwa/sd/python/ftputil/ftputil/stat.py", line 627, in _real_lstat "550 {0}: no such file or directory".format(path)) ftputil.error.PermanentError: 550 /walk_test/nonexistent: no such file or directory Debugging info: ftputil 3.2, Python 3.4.1 (linux)
Because the filename has always been present during my debugging, I hadn't even thought about adding the directory/file name explicitly.
Which FTP server are you using? If it doesn't include the file name by default, maybe there's a configuration option you could change (if you can configure the server at all).
I also tried
FTPHost.open
to get anFTPIOError
. The directory isn't included here, but at least the file name:>>> host.open("walk_test/something_nonexistent") Traceback (most recent call last): File "/home/schwa/sd/python/ftputil/ftputil/file.py", line 92, in _open self._conn = self._session.transfercmd(command) File "/usr/lib64/python3.4/ftplib.py", line 398, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "/usr/lib64/python3.4/ftplib.py", line 364, in ntransfercmd resp = self.sendcmd(cmd) File "/usr/lib64/python3.4/ftplib.py", line 272, in sendcmd return self.getresp() File "/usr/lib64/python3.4/ftplib.py", line 245, in getresp raise error_perm(resp) ftplib.error_perm: 550 Can't open something_nonexistent: No such file or directory
(I used
something_nonexistent
for the name to make clear that it's not a hard-coded text from the server.)
Whether the directory name is included in the server response depends on the server. I don't want to modify the message because I might accidentally remove other important information, so I set the ticket to "wontfix".
Please reopen the ticket if you have a suggestion how to handle the problem.