michaellukashov / Far-NetBox

SFTP/SCP/FTP/FTPS/WebDAV/S3 client for Far Manager 3 (http://farmanager.com/)
https://forum.farmanager.com/viewtopic.php?t=6317
GNU General Public License v2.0
161 stars 52 forks source link

"Resume" for FTP connection overwrites the destination file #228

Open dmak opened 7 years ago

dmak commented 7 years ago

When I choose "Resume" and connection is interrupted, NetBox re-establishes the connection automatically after some timeout (OK), but then automatically does "overwrite" of destination file (wrong). So each time the connection is reset/interrupted, the destination file is reset and upload begins from scratch. Expected that interrupted upload is resumed.

NetBox v2.2.0.427, also posted to forum.

VictorVG commented 7 years ago

Давайте по-русски писать, и смотреть что "имеем с гуся" - главное мы имеем спецификацию протокола RFC 959 : FILE TRANSFER PROTOCOL (FTP) оговаривающую в п. 3.5 (стр.24) условия при которых происходит возобновление прерванной передачи данных:

3.5. ERROR RECOVERY AND RESTART

  There is no provision for detecting bits lost or scrambled in data
  transfer; this level of error control is handled by the TCP.
  However, a restart procedure is provided to protect users from
  gross system failures (including failures of a host, an
  FTP-process, or the underlying network).

  The restart procedure is defined only for the block and compressed
  modes of data transfer.  It requires the sender of data to insert
  a special marker code in the data stream with some marker
  information.  The marker information has meaning only to the
  sender, but must consist of printable characters in the default or
  negotiated language of the control connection (ASCII or EBCDIC).
  The marker could represent a bit-count, a record-count, or any
  other information by which a system may identify a data
  checkpoint.  The receiver of data, if it implements the restart
  procedure, would then mark the corresponding position of this
  marker in the receiving system, and return this information to the
  user.

  In the event of a system failure, the user can restart the data
  transfer by identifying the marker point with the FTP restart
  procedure.  The following example illustrates the use of the
  restart procedure.

  The sender of the data inserts an appropriate marker block in the
  data stream at a convenient point.  The receiving host marks the
  corresponding data point in its file system and conveys the last
  known sender and receiver marker information to the user, either
  directly or over the control connection in a 110 reply (depending
  on who is the sender).  In the event of a system failure, the user
  or controller process restarts the server at the last server
  marker by sending a restart command with server's marker code as
  its argument.  The restart command is transmitted over the control
  connection and is immediately followed by the command (such as
  RETR, STOR or LIST) which was being executed when the system
  failure occurred.

и если соединение с удалённым сервером не отвечает условиям спецификации протокола, по возобновления передачи данных не происходит, частично переданный файл удаляется и операция начинается с начала в полном соответствии со спецификацией протокола FTP.

dmak commented 7 years ago

По-русски – нет проблем. В дополнение к RFC 959 от 1985 года есть ещё RFC 3659:

5.2. Error Recovery and Restart

STREAM mode transfers with FILE STRUcture may be restarted even though no restart marker has been transferred in addition to the data itself. This is done by using the SIZE command, if needed, in combination with the RESTART (REST) command, and one of the standard file transfer commands.

VictorVG commented 7 years ago

Но у нас в любом случае RFC959 основа, и если условия спецификации не соблюдаются процедура передачи начнётся с нуля. Давайте исходить из этого общего предположения и проверять от него чтобы быть уверенными что мы не встретились с общей ситуацией. И если в случае когда протокол допускает возобновление передачи с конца последнего успешно переданного блока происходит передача с начала файла, будем смотреть где происходит сброс счётчика переданных байт.

Я думаю что это происходит в WinSCP, и для проверки глянул бы как она себя ведёт в такой ситуации? FileZilla продолжает передачу с учётом факта обрыва, по крайней мере под демоном я это вижу, а WinSCP я не пользуюсь потому наблюдений по ней у меня нет.

dmak commented 7 years ago

Согласно Wikipedia, команда MLSD является частью RFC3659. Эту команду я вижу в логе NetBox, то есть, NetBox уже использует эту спецификацию.

Как я понимаю, единственный вариант продолжить закачку по протоколу RFC959 – это использовать команду LIST (?) + APPE (у вас есть с использованием этой команды?), в то время как по протоколу RFC3659 – это SIZE + REST + STOR (все поддерживаются сервером). В моём случае сервер отвечает клиенту, что он поддерживает докачку в STREAM mode по протоколу RFC3659:

FEAT
211-Features:
 SIZE
 REST STREAM
 MDTM
 MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
 ...

То есть, я не вижу причины, почему докачка невозможна. Вы говорите, что соединение с удалённым сервером не отвечает условиям спецификации протокола – какие именно должны быть соблюдены условия?

Дополнительная информация: Use of FTP “append” command.

Я думаю что это происходит в WinSCP

WinSCP тоже ведёт себя неприлично. Когда соединение обрывается (я отключал WiFi), он перелогинивается, но почему-то при повторной отправке файла возникает control connection timeout:

> 2017-04-14 15:41:00.431 TYPE I
< 2017-04-14 15:41:00.431 200 Type set to I
> 2017-04-14 15:41:00.431 PORT 10,0,0,36,228,168
< 2017-04-14 15:41:00.431 200 PORT command successful
> 2017-04-14 15:41:00.431 REST 114066508
< 2017-04-14 15:41:00.441 350 Restarting at 114066508. Send STORE or RETRIEVE to initiate transfer
> 2017-04-14 15:41:00.441 STOR 033.psd
< 2017-04-14 15:41:00.451 150 Opening BINARY mode data connection for 033.psd
. 2017-04-14 15:41:15.343 Timeout detected. (control connection)
. 2017-04-14 15:41:15.343 Copying files to remote side failed.
. 2017-04-14 15:41:15.343 Connection was lost, asking what to do.

При использовании FileZilla проблемы с докачкой не было. Тем не менее, были замечены два бага:

VictorVG commented 7 years ago

Ну, вики великий "авторитет" - любая статья печатаемая там не появится без "одобрямс" со стороны т.н. "опытных участников" среди которых нет ни одного научного работника либо инженера, зато присутствуют исключительно маркетологи и сотрудники отделов продаж от спонсоров проекта - это пару раз признавали его руководители.:) Не просто так там к примеру в статьях по ЦПУ Alpha AXP приведена совсем иная техническая информация чем та, что печаталась в DEC Technical Journal - в 1997 права на ЦП Alpha AXP купила Intel и сразу объявила о сворачивании проекта как "морально устаревшего и исчерпавшего потенциал развития" хотя при его анонсе был определён его жизненный цикл - 25 лет. Но после полного и вдобавок с грубыми ошибками копирования архитектуры Alpha AXP для своих i586+/Itanium Intel купила права и закрыла проект, а до того производила DEC Chip AXP 2106x и честно воровала чужие идеи.:)

Что до FTP - RFC-959 это база протокола которую обязаны реализовывать все, а RFC3659 это её расширение и её могут реализовывать уже не все, хотя она и относится к числу настоятельно рекомендуемых. У меня pure-ftpd демон реализует оба RFC, но принудительно заставляет клиента работать по RFC-3659.

То, что мы с вами видим в логе WinSCP говорит нам "Процедура докачки не реализована в WinSCP", а в FileZilla упоминаемая вами проблема FTPS/TLS от 2015-го года давно исправлена, а вывод в лог отправленных на сервер команд - для этого у FZ есть настройки и коли кому надо тот под себя настраивает вид лога.

dmak commented 7 years ago

Я понимаю, что не всему написанному на wikipedia нужно верить. Если у вас есть замечания к именно той статье, на которую я привёл ссылку, то давайте будем более конструктивны. Ваше замечание насчёт CPU Alpha AXP вы можете занести прямо на страничку Wikipedia, в крайнем случае есть закладка "Talks" где вряд ли кто-то будет вам закрывать рот – напишите об этом.

Клиент WinSCP посылает серверу команды из RFC-3659, соответственно он должен правильно его реализовывать. Но WinSCP хоты бы "пытается" начать докачку, в то время как NetBox сразу перезаписывает, без предупреждения.

FileZilla был скачен мною сегодня, версия 3.25.1. Я без особых претензий к этому клиенту, но эту ошибку эту я не придумал. Возможно, что-то настроил в нём не так – надо посмотреть повнимательнее. А консоль неконсистентна: вначале он пишет в консоль

Command:    PWD
Command:    TYPE I
Command:    PASV
Command:    MLSD

но после восстановления от сбоя команды, посылаемые на сервер, не попадают в консоль. Для кого-то это может показаться логичным, для меня – нет. Консоль = верхнее окошко в GUI, а не лог-файл на файловой системе. В любом случае, докачка в нём работает, если не форсировать FTPS/TLS.

VictorVG commented 7 years ago

Реализация протоколов восстановления соединения зависит от ответа сервера - какой режим он может реализовать, так что тут надо смотреть.

dmak commented 7 years ago

Реализация протоколов восстановления соединения зависит от ответа сервера

Я не уверен, что на сегодняшний день есть хоть один "серьёзный" FTP сервер, который не реализует RFC-3659. В конце-концов, ничто не мешает объявить, что NetBox работает только с FTP серверами, которые реализуют RFC-3659. По факту я не уверен, что кто-то тестировал NetBox на "чистом" RFC-959.

Я начал параллельную дискуссию насчёт проблемы в WinSCP на форуме. Пока не понятно, в чём именно дело, но для WinSCP есть workaround: использовать passive mode.

VictorVG commented 7 years ago

Ну, с ворграундом понятно - в пассивном режиме именно сервер выбирает набор портов соединения, а в активном наоборот - клиент. А это не все сервера разрешают из соображений безопасности. Насчёт реализации RFC-959 без RFC-3659 - роутер ZyXEL, NDMS 2.0.8C (LINUX), pure-ftpd :

Protocol - Server and protocol information Server information 21-Remote system UNIX Type: L8 21-Session protocol FTP 21-Compression: No

Protocol capabilities/information

35-Can change permissions: Yes 35-Can change owner/group: No 35-Can execute arbitrary command: Protocol commands only 35-Can create symlink/hardlink: No/No 35-Can lookup user groups: No 35-Can duplicate remote files: No 35-Can check available space: No 35-Can calculate file checksum No 35-Native text (ASCII) mode transfers: No

Additional protocol information

NetBox = The server supports these FTP additional features: EPRT IDLE MDTM SIZE MFMT REST STREAM MLST type;size;sizd;modify;UNIX.mode;UNIX.uid;UNIX.gid;unique; MLSD UTF8 ESTA PASV EPSV SPSV ESTP

для дома достаточно, т.к. девайс стоит исключительно в качестве сетевого принт-сервера для лазерника, а поелику на HDD есть свободное место, то там расположен вспомогательный FTP с локальной файло-помойкой. Скорость записи не ахти - USB 2.0 более 15 - 18 Мб/с не позволяет, но для "сегодня скинуть, завтра флешкой заберут" хватает.

dmak commented 7 years ago

Команды в Additional protocol information – это то, что поддерживает сервер? Если да, то почти все эти команды выходят за рамки RFC-959. Иначе, возможно, в прошивку положили обрезанную версию pure-ftpd, поскольку в стандартной версии он реализует массу RFC:

Так или иначе, мне кажется, можно последовать принципу 80/20, то есть, реализовав поддержку докачки по протоколу RFC-3659 покрыть 80% всех usecases.

VictorVG commented 7 years ago

Похоже да, прошивка имеет размер 8 Мб чтобы влезала в однокристалку на которой собран роутер. С идеей расширения согласен.

dmak commented 6 years ago

Для справки. Докачку в WinSCP в active mode уже с год как починили (в passive работала и раньше):

. 2018-09-04 23:04:26.969 Binary transfer mode selected.
. 2018-09-04 23:04:26.969 Starting upload of D:\backup.rar
> 2018-09-04 23:04:52.026 TYPE I
< 2018-09-04 23:04:52.031 200 Type set to I
> 2018-09-04 23:04:52.031 PORT 10,0,14,87,238,198
< 2018-09-04 23:04:52.033 200 PORT command successful
> 2018-09-04 23:04:52.033 REST 3897103249
< 2018-09-04 23:04:52.036 350 Restarting at 3897103249. Send STORE or RETRIEVE to initiate transfer
> 2018-09-04 23:04:52.036 STOR backup.rar
< 2018-09-04 23:04:52.043 150 Opening BINARY mode data connection for backup.rar
. 2018-09-04 23:04:52.044 Session ID reused
. 2018-09-04 23:04:52.045 Using TLSv1.2, cipher TLSv1/SSLv3: ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA, ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
. 2018-09-04 23:04:52.045 TLS connection established
. 2018-09-04 23:04:53.044 Increasing send buffer from 262144 to 1048576
...
VictorVG commented 6 years ago

А RFC-1738 чинить и не планируют - год назад им написал по поводу #255 и на днях ответили - IETF RFC are recommendations, but their strict adherence is not necessary. - IETF RFC это рекомендации, но их строгое соблюдение не обязательно. :)

dmak commented 6 years ago

Не совсем понимаю, как RFC-1738 связан с текущим issue про докачку по FTP. А у вас есть лог того, как выглядит докачка на каком-нибудь сервере? Мне любопытно, как это выглядит.

VictorVG commented 6 years ago

RFC-1738 Uniform Resource Locators (URL) - поломали, так что тут можно получить проблему установки соединения в процессе докачки.

Под рукой лога нет, но по памяти там будет запись о передаче данных с позиции ... бит .

dmak commented 6 years ago

Под рукой лога нет, но по памяти там будет запись о передаче данных с позиции ... бит.

Тем не менее, интересен весь лог, с самого начала (USER, PASS, FEAT и т.д.)

VictorVG commented 6 years ago

Будет - дам, пока случая его получить не было. У меня давненько связь не рвалась.

dmak commented 6 years ago

У меня давненько связь не рвалась.

Это легко можно сэмулировать отключив во время upload на минутку WiFi в system tray, или вынув сетевой кабель из сокета в сетевой карте.

VictorVG commented 6 years ago

Только одна труднгость :) - железо стоит в стойке и к кабелям не подберёшся. Потому -будет момент - будет и лог,а специально играть нет времени.:(