Что: 695e1f8e4ac9315fe88b02b7114ad6c1165e3d6f Когда: 2018-06-02 17:37:57+03:00 ------------------------------------------------------------------------ Темы: go nncp ------------------------------------------------------------------------ Зарелизил NNCP 3.2 с исправлением зависимости от баги в самом Go https://lists.cypherpunks.ru/pipermail/nncp-devel/2018-June/000069.html Использовал сегодня nncp-bundle команду для перелива одних данных. Ничего не падает, но не работает. -debug говорит что корявый tar заголовок встречает в потоке. Оказалось что в Go 1.9 archive/tar библиотека не создавала валидные tar архивы с длинными путями (более 100 символов). А я nncp-bundle код делал рассматривая как-раз именно эти архивы. Более того, BSD tar успешно их обрабатывал. В Go 1.10 они исправили багу в https://github.com/golang/go/issues/9683 и начали создавать корректные архивы которые уже nncp-bundle не в состоянии был обработать. В чём проблема? Мне необходимо в потоке байт (которые например льются с CD-ROM, ленты, просто блочного устройства) искать так называемые NNCP bundle-ы, которые чисто технически являются tar архивом с пакетами сложенными в виде: NNCP/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A/HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA где (в данном конкретном случае): * 2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ -- получатель * PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A -- отправитель * HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA -- шифрованный пакет Всё это в Base32 и поэтому суммарная длина такого пути -- 163 символа. Сократить это можно каким-нибудь Base64, но оно всё-равно будет длиннее 100 символов и менее удобно для использования человеком. tar заголовок (USTAR и PAX) имеет фиксированные позиции для хранения путей. Но в нём два поля: само имя файла и некий префикс который к нему можно добавить. Длина имени файла ограничена сотней символов. Для чего я добавлял NNCP/ директорию? Чтобы как-раз таки именно его искать в потоке байт и пытаться интерпретировать последующие байты как tar заголовок. Go 1.9 archive/tar библиотека не проверяла длину пути и буквально просто засовывала эти 163 байта. Почему BSD tar это читал? Видимо ориентировался по нулевым байтам каким-нибудь. Просто повезло. Go 1.10 библиотека стала делать корректно: определяет длину пути и разбивает его на части. Имя пакета (в моём случае) шло в имя файла, а остальное отправлялось в середине заголовка в поле префикса. В итоге "NNCP/" оказался где-то в середине заголовка и вся логика по поиску tar заголовка ломалась. А искать название пакета я не могу потому-что это псевдослучайная строка. Можно конечно усложнить сам код поиска и в памяти, найдя NNCP/, "расчитывать" поток байт назад чтобы найти начало заголовка. Я решил более простым (с точки зрения кода) способом, но требующим чуть больше места для хранения. Я просто добавляю перед каждым файлом "NNCP" директорию в архив. Так как её длина маленькая, то она помещается полностью в поле имени файла и находится в начале архива, как и прежде. В коде я, как и прежде, ищу "NNCP", интерпретирую начиная с него байты как tar заголовок, проверяю что это директория, дальше считываю следующий заголовок, который уже должен быть файлом с NNCP пакетом. То есть, теперь хранится вот так: NNCP/ NNCP/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/PKTJQKU5M62LF3IND7JTPIJB5A45FSSQ7TEP4SGGT26RW4WAE76A/HKKECXX7PWZ6YCDMWU74BT6OYKDBZLKF25NI4S3LZ3CJ57WTVMAA ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%97%D0%B0%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D0%B8%D0%BB%20NNCP%203.2%20%D1%81%20%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8%20%D0%BE%D1%82%20%D0%B1%D0%B0%D0%B3%D0%B8%20%D0%B2%20%D1%81%D0%B0%D0%BC%D0%BE%D0%BC%20Go%20%28695e1f8e4ac9315fe88b02b7114ad6c1165e3d6f%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0