SM>> При наличии документации, а её я все-таки нарыл, он вполне хорошо SM>> настраивается. Другое дело, что она не столь подробная, как хотелось SM>> бы, но в большинстве случаев все нюансы выясняются методом научного SM>> тыка без особо фатальных последствий. Тебе ни кто не мешает настроить SM>> его сначала в сторонке, а потом просто переключиться, когда ты будешь SM>> уверен, что все работает так, как ты хочешь. Да, повторюсь, описание SM>> краткое, но в большинстве случаев вполне достаточное.
OP> Писал уже ж, не в настройках дело. Hастроить и заставить запуститься OP> действительно не трудно. Вопрос в другом - в управляемости и OP> предсказуемости поведения в различных и особенно в нестандартных OP> ситуациях. Для тупиковой ноды это не очень критично. Для крупного OP> раздающего узла может быть не просто заметно, а очень даже чересчур OP> нехорошо заметно.
Я же говорю, "настраиваешь его сначала в сторонке". Откатываешь на нем все, потом только допускаешь его к основной работе. В случае с Виндой это можно организовать как-то так: ====== toss.cmd ===== @echo off for %%I in (*.pkt *.sa? *.mo? *.tu? *.th? *.we? *.su? *.fr?) do copy %%I \fido\hpt.in
fastecho toss
htp toss
=====================
OP> Риск. конечно, дело благородное, но он должен ведь быть оправдан! :)
А он и оправдан. Ты получаешь более работоспособный в нынешних условиях тоссер.
Have nice nights! Stas Mishchenkov.
--- NudeGrand * Origin: Have a nice carrot! Brother Rabbit. Crimea. (2:460/58.10)
