Pull to refresh

Comments 44

Не пробовали использовать планшет как usb модем?

Ну в данном случае этот ПК нельзя было выпускать в интернет. Но у других может быть вариант что провайдер ограничивает раздачу интернета с планшета или телефона.

В интернет нельзя, но подключать USB можно, и файлы из интернетов можно :)
Ох уж эта безопасность ;)

Вариант, когда провайдер ограничивает раздачу, обычно можно обойти так:


  • поставить на мобильное устройство socks5 сервер (есть разные приложения)
  • активировать точку доступа на мобильном устройстве
  • с ПК подключиться к точке доступа используя ручные настройки (вместо DHCP) без задания шлюза
  • запустить на ПК торрент клиент и прописать ему настройки socks прокси.

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

и прописать ему настройки socks прокси
Проще ProxyCap или proxychains поставить, они умеют трафик любой программы через прокси заворачивать, даже если сама программа настройку прокси не поддерживает. Причём с поддержкой удалённого DNS.
У автора была задача не выпускать ПК в интернет, и такой частичный выпуск, возможно, мог сгодиться.
А так верно замечено, что можно пользоваться соксификаторами, если удобно.

Для обхода провайдерских ограничений на раздачу трафика есть и другие способы, которые могут быть более удобными, но вариант с socks один из самых простых в настройке, не нужно никаких плясок с VPN и файерволом, не нужен рут на мобильном, работает довольно надёжно с любыми ОС.
Из возможных уязвимых мест такого подхода — нешифрованный трафик с ПК, там может быть не мобильный user-agent и другая информация, если провайдер заморочится, могут возникнуть подозрения.

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

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

При этом оператор не ограничивает торренты?

Могло не повезти и клиент, обнаружив отсутствие файла, пересоздал бы список загруженных фрагментов. В общем, не для каждого клиента рецепт.

Если поставить на паузу переместить файл и закрыть клиент, то после открытия и запуска так и происходит.

я думаю имееться в виду повезло с клиентом. С uTorrent это не прокатит например. Файл вы не удалите пока не ОСТАНОВИТЕ закачку. Не пауза, а именно стоп. Затем при попытке продолжить закачку она упадет с ошибкой «файл не найден» пока не запустите «обновить хэш»

Вот только сейчас узнал что есть uTorrent под Android.

Файл вы не удалите пока не ОСТАНОВИТЕ закачку.
Это кто ж вам запретит его удалить?

Другое дело, что удалить-то вы его удалите, а вот место не освободится… можно попробовать fallocate, конечно, но чем это закончится не очень ясно: там были проблемы с безопасностью и на многих телефонах fallocate выпилили… даже CTS тест есть.
Torrent-клиент очень странный. Мало того, что позволяет удалить находящийся «в работе» файл, так ещё и выставление флажка sparse — это, по сути, ошибка в клиенте.

Почему установка sparse флага это ошибка?

Этот флажок программа должна выставлять на файле, если она предполагает, что там кучи нулей будут в содержимом. Для торрента это (в общем случае) неверно. Функциональности типа «скачать только вторую половину файла» я в торрент-клиентах тоже не видел. Поэтому торрент-клиенту, вроде бы, незачем помечать файл sparse. Единственная возможная причина — «не выделять сразу весь объём файла, а то система из соображений безопасности начнёт его весь заполнять нулями, а это долго». Но это сомнительная оптимизация, поскольку в результате файл получится сильно фрагментированным.

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


Так-же если отменили скачивание когда уже в файле есть несколько частей то они останутся и будут раздаваться а файл опять же не будет занимать много места.


Ну и удаление наверно доступно по тем же причинам. Так как в уже не нужном файле может быть много загруженных данных. Его можно удалить и освободить место для остальных.


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


Ну и клиент будет вечно бороться с антивирусом если втророй будет удалять файл а первый его перекачивать автоматически.

Куски начал и концов ненужных файлов uTorrent (например) помещает в отдельный файл со странным именем ("~uTorrentPartFile_207807000.dat"). И это достаточно удобный вариант, т.к. недозагруженные куски не перемешиваются с полными файлами при просмотре каталога пользователем.

В целом, разные ситуации, в которых sparse полезен, придумать можно, но они выглядят не слишком значительными. А вот фрагментация получающихся таким образом файлов должна быть просто ужасающая (интересно было бы проверить численно). С другой стороны, если это фильм на одноразовый просмотр, то и не жалко, пусть себе винчестер тарахтит при просмотре…

А возможность удаления файла — это всё-таки очень странно. Логично было бы в начале скачивания открыть файл на запись и закрыть только после окончания загрузки (и тогда он так просто не удалится). А они, получается, на каждый кусочек: открыли файл — записали кусочек — закрыли файл?
А вот фрагментация получающихся таким образом файлов должна быть просто ужасающая (интересно было бы проверить численно).
На SSD пофиг…

Логично было бы в начале скачивания открыть файл на запись и закрыть только после окончания загрузки (и тогда он так просто не удалится).
Ещё раз: не лезьте со своими Windows-подходами в телефон. Удалится прекрасно.

А они, получается, на каждый кусочек: открыли файл — записали кусочек — закрыли файл?
Разумный подход, на самом деле: файлов в торренте может быть и сто тысяч, а файловые дескрипторы — ограниченный ресурс.

Планшет рутануть, замонтировать с компа директорию через самбу и хоть терабайты можно выносить. Или через otg (если планшет умеет) внешний диск зацепить. Но блин так из кусочков каждый раз собирать.....

Внешний жёсткий диск по otg не получилось потключить так как диску нужно было внешнее питание. Без него планшет диск не тянет.

Можно сколхозить шнур отг+внешнее питание, на 4пда даже тема есть по этому вопросу.
Подскажите, пожалуйста, как? DroidSMB, SambaDroid и IceColdApps как-то не работают, LANdrive приходится каждый час, каждый раз руками подталкивать.

Честно говоря, уже не вспомню каким именно клиентом это делал на стике мк802-iii, но работало стабильно. Помню только что гуглил что-то типа android mount smb и дальше перебирал все известные клиенты на 4пда.

Если я правильно понял, то после паузы клиент будет отдавать нули другим peer'ам, думая что эти блоки он уже скачал. Или я что-то напутал?

Скорей всего так и есть. Поэтому после полного скачивания нужно обязательно запустить перепроверку торрента чтоб клиент понял какие блоки у него действительно есть и раздавал только их. Ну и надо снять галочку с файла чтоб он не пытался его опять докачать.

Как запустить перепроверку после полного скачивания если полное скачивание невозможно из-за нехватки места на планшете?

Так после окончания процедуры описанной в статье у торрент клиента будет иллюзия что скачан торрент полностью(что в общем то правда). Только вот данные ему доступны не полностью. Поэтому снимаем галку с файла и запускаем перепроверку.

Так торрент клиент на планшете не сможет проверить, так как куски файла не доступны полностью.
Самый простой пример — торрентом является один какой-нибудь ISO файл.

В последнем цикле после проверки останутся части которые полнстью скачаны за последний цикл а также части которые которые были скачаны частично на начало цикла. Части которые были скачаны частично на момент запуска последнего цикла скачаются 2 раза так как хеш в первый раз не сойдётся.


Можете провести эсперимент. У меня всё получилось с клиентом Flud.

А что помешает ему проверить? Нули на месте тех кусков файла вполне доступны клиенту.

Где то в азии начинаются проекты по 6g со скоростью до 1 Тбит/с, миниатюрные флеш накопители обьемом 256-512 Гб уже давно стали ширпотребом, а он тут файлы по 4Гб кусками перекидывает, мог бы еще усложнить fat системой и кидать по 2Гб (но это наверное в след. статье ?), куда же ты паря смотришь, что ты делаешь, иди учись, работай и не занимайся ерундой!
есть торрент-клиенты с последовательной скачкой данных (например, qbittorent), то есть не пришлось бы потом искать части и сравнивать их с null'ами. Не знаю правда, есть ли такая версия торрент-клиента для планшета.

Во Flud тоже есть последовательная скачка. Это может ускорить слияние. Но даже при ней не представляю как алгоритм улучшить. На данный момент он упирается только в скорость чтения/записи.


Ну и если каждый после такой процедуры оставит хвост файла на раздаче то может оказаться что доступен останется только он. А при рандомной загрузке у каждого в последней части будут разные места заполнены.

Я как всегда не смог сдержать зуд реализовать всё то-же самое шеллскриптом.
Если исходные версии файла из-под торрента числом 4 и называются payload_1, payload_2, payload_3 и payload_4 и известно, что торрент побит на сегменты в 1Мб (можно посмотреть в клиенте или выставить своё значение, хоть 4кб), то это скрипт склеит файл:


mkdir brokenfragments
cd brokenfragments
for i in {1..4}; do
    split --numeric-suffixes --bytes=1M --suffix-length=4 ../payload_${i} payload_${i}_
done
for i in payload_1_* ; do
    N=${i#payload_1_}
    for j in {1..4}; do
        if <payload_${j}_${N} tr -d '\0' | read -n 1 ; then
            cp payload_${j}_${N} payload_x_$N 
            continue;
        fi
    done;
done
cat payload_x_* > ../payload_x

Если в исходном файле свои собственные нули, то возможны нюансы. Команда <файл tr -d '\0' | read -n 1 (со стековерфло) удаляет из файла "файл" нули и смотрит, не осталось ли чего; возвращает успех если не всё — нули.

Я не спец по шеллскрипту но не думаю что операционная система обрадуется файлу на каждый 1MB данных при обьёме в 16GB каждой части. Пустые сегменты будут занимать 4KB но также будут иметь запись в файловой таблице.

Винда не радуется, линуксу норм.


Линейное чтение правильнее, но на шелле я пока не придумал как это сделать элегантно или хотя бы читаемо.

А на винде-то что не так? Или вы под "виндой" понимаете Проводник?

Очень медленно работает. Тестовый прогон с 16кб фрагментами у меня весь день собирается, ещё не готово.

Если вы пишете миллион файлов на FAT — так и будет.

NTFS же. И только четверть миллиона.

Возможно, это поможет.

Microsoft recommends turning off short filename creation if you have more than 300k files in a folder


Sign up to leave a comment.

Articles