DC++ лишние дисковые операции

Привет.
Когда DC++ клиент качает файл он выполняет частое открытие и закрытие временного файла *TTH.dctmp в который записываются полученные сегменты от разных пользователей
т.к. антивирусные мониторы при операции открытия файла выполняю анализ на предмет вирусни. В связи с этим рекомендуется вашему антивирусу добавить в исключение расширение файла *.dctmp - это снизит нагрузку на систему.
у себя в последних билдах FlylinkDC++ я исправил эту особенность и временный файл открывается один раз и закрывается только после того, как скачка всех сегментов файла окончательно завершится.

Ловится такая активность программой Process Monitor вот таким фильтром:

Обновить свой флайлинк до последней версии можно через
меню -> помощь -> проверка обновлений

HFS от Mac в Windows чуток глючит?

Привет.
Пользователь в винде примонтировал файловую систему от MacOS (BOOTCAMP)
но у него вылез баг - при запуске флайлинка он повторно хеширует файлы расположенные на этом диске
причина оказалась в том, что размер файла показываемый под виндой всегда кратен размеру кластера
но если читать файл, то читается точный размер файла.
алгоритм хеширования через FidFile сканирует каталоги и анализирует размер файлов и временные метки
сравнивая их со значениями из базы. а в этом случае получается так, что размер файла не равен прочитанному 
в результате чего файл посылается в "вечное" повторное хеширование.
Кто встречал такое и как лучше это обойти если эта "фича" драйвера? 

Пример файла в картинках:

Автоматически определяем домашний роутер

Привет.
Новые версии FlylinkDC++ умеют детектировать подключение к интернету через роутер а также помогает узнать
какой у вас IP (белый/серый)
Алгоритм
1. Если в системе дефолтный шлюз = 192.168.1.1 или 192.168.0.1
автоматически включается режим подключения UPnP и рисуется ротуер
2. Если IP адрес полученный от upnp роутера не относится к приватной сети:
10.0.0.0/8
127.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
или к Shared Address Space:
100.64.0.0/10
вероятно у вас белый адрес(динамический или статический) 
и при нажатии кнопки "Тест портов и определение IP"
внешний WAN IP будет совпадать с полученным IP от роутера.
Если IP различаются, то у вас серый IP и вы находитесь за NAT-ом провайдера
при этом с внешними хабами работа возможна только в пассивном режиме.
У кого есть замечания - пишите в тему/почту

 

Также в связи с тем, что большинство wifi-роутеров сейчас имеют upnp по умолчанию включенным
реализован автоматически переход в пассивный режим если провалилась попытка проброса портов
в этом случае пользователь сможет искать и качать файлики в пассивном режиме через хаб.

Заметаем следы скачки файлов

Всем привет!
Пользователи просят
* Отключать историю хранения обмена файлами
* Возможность выборочно удалить файл из лога  (шифруются :)
В сборке 18108 и выше такая функция реализована.

Удаление выбранных файлов:













Полностью отключить хранение истории в базе данных
можно установив в настройках значение = 0

Ошибка обновлений + кэширующий прокси

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

 


При обновление сверяются контрольные суммы всех файлов полученные с сервера для исключения не консистентной копии.
и получается, что провайдер отдал пользователю старую версию файла
http://update.fly-server.ru/update/5xx/beta/FlylinkDC_x64.exe.bz2
меркер версии хранится в файле рядом  
http://update.fly-server.ru/update/5xx/beta/Update5_beta.xml
но этот файл был отдан уже от новой версии
Детальнее проблема описана на одном из форумов провайдера http://help.unet.by/question/details/id/361926
В чем может быть причина?
может у меня что-то не так?
или это проблема локальная и исключительно на стороне провайдера.
Может кэшу нужна привилегия на сканирования каталога
http://update.fly-server.ru/update/5xx/beta/
которую я отключил - т.к. флайлинк сам знает какие файлы качать и их прямые урлы
после чтения файла конфигурации обновки
http://update.fly-server.ru/update/5xx/beta/Update5_beta.xml

Сохраняем историю обмена файлами в базе sqlite

Несколько раз меня пользователи просили приделать эту функцию
т.к. искать по логам не удобно.
С билда 18034 на бета-канале в автообновлении
или тут http://www.fly-server.ru/install/r5xx/beta/
доступна новая версия.
Пользователям с большой нагрузкой по трафику прошу протестировать
насколько эта операция окажется ресурсоемкой (зависания и т.д.)
Об ошибках пишите на почту pavel.pimenov@gmail.com
или анонимно в чат поддержки dchub://dc.fly-server.ru

Вся информация хранится в базе данных FlylinkDC_transfers.sqlite
в виде одной не нормализованной таблицы (рис 2)
Этот файл всегда можно безболезненно удалить
потеряется только история закачек/отдач

В планах добавить
- Поиск по атрибутам
- Настройку ротации файла для удаления старых записей
- Сохранение статистики от кого получены сегменты файла (возможно оно не нужно)
- Экспорт в Эксель
- Что-то еще.... предлагаете.

FlylinkDC++ и Doctor Dump

Всем привет.
Успешно обновился на новую версию сбора и анализа дампов падения.
Фалйлинк за 2 года использования сервиса https://drdump.com стал стабильнее и было 
исправлено львиная доля ошибок не повторяющаяся на конфигурации разработчика
Приведу два последних примера быстрой локализации проблемы с помощью "доктора-дампа"
1. После перехода на VC++2013 я не знал, что он по умолчанию включает
опцию использования инструкций SSE2 и этом привело к тому, что пользователи 
на старых процессорах типа Athlon XP после получения обновлений
сразу начали падать при инициализации openssl
я успел это заметить после получения 23 дамп 
(вероятно эти 23 человека сразу снесли глючный флайлинк и больше никогда его не поставят) 
без доктора - эта цифра была-бы больше:-(
Программой пользуются в отдаленных уголках СНГ где такой старый 
процессор еще считается нормальным... я думаю быстрым фиксом я спас остальных 
обладателей этого процессора
https://drdump.com/Problem.aspx?ProblemID=102637

2.  Ошибка в реализации функции pow при использовании компилятора VC++2013 старых версий винды
https://drdump.com/Problem.aspx?ProblemID=102616

В данном случае задето меньше пользователей
т.к. она возникла только у тех у кого виста или 7-ка без SP1
падало при хешировании новых медиа-файлов в mediainfo-lib
Ошибка оказалась известная и способ обхода описан в инете.
Быстро пофкисил во флайлинке падение и выпустил обновление
 + послал патч автору библиотеки medainfo
http://sourceforge.net/p/mediainfo/code/6567/
и даже получил за это спасибки в его ченж-логе :)