stg-34

mv - это переименование файлов. вообще-то... Понимаешь, ценность таких советов нулевая. Какой смысл давать совет использовать операцию, которая гарантированно работает в отсутсвии физ. сбоев, если мы обсуждаем физ. сбои? Сорри, если обидел.

Не согласен. 1. ставим флаг начала операции (создаем bak), и одновременно запоминаем предыдущее состояние 2. переисываем файл 3. удаляем флаг, тем самым подтверждая, что операция прошла успешно. Если сбой происходит в п.1 файл остается не затронутым Если сбой происходит в п.2, у нас нет отметки о завершении операции, востанавливаем по данным сохраненным в п.1 Если сбой происходит в п.3, то получается предыдущий вариант сбоя. Восстановление такое же. Т.е. я не вижу как в данной схеме можно получить поломанные данные.

Ой, сомневаюсь, что тебе поможет журналируемая fs. Мало того, что не поставят все любители старгейзера себе журнальную fs, так с ней тоже работать надо уметь правильно :) Не, это просто умиляет Перечитай тему о чем мы говорим. Если нет времени, то могу сообщить: мы говорим о сохранении целостности данных при физическом сбое оборудования. Например выключении питания или нажатии кнопки ресет. А ты рассказываешь как гарантировано переписать файл в отсутсвие физичесих сбоев. Спасибо, но в остутисвии физических сбоев переписать гарантированно файл и дурак сможет. По поводу вольной тракто

Я, в целом, согласен, как подтверждение этого, в стг было добавлено создание bak-файлов. И как было написано пару постов выше повышает надежность. Почему у тебя не появляются баки, не скажу, надо смотреть, мне кажется или 1. у тебя старая версия, которая не поддерживает этот функционал 2. ты куда-то не туда прописал в конфиге эти опции. ПС: UPS, RAID и журналируемые ФС полезные штуки

bash установлен?

Есть, есть. Это операция не на один такт, может эта операция и уменьшает вероятность обнуления, но можно попасть на момент, когда старый (перезаписываемый) файл удален, а операция переименования нового не завершена. Короче та же фигня только сбоку. В общем, если бы можно было выполнить эти операции как одну транзакцию, то да, но, к сожалению это не так. На самом деле спасает журналируемая ФС, или варианты журнлирования "руками", как сделано у меня

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

Последний сервер, с stg.dp.ua или с local.com?

А бак файлы вообще появились? И какие настройки ты выставил?

Настроить firewall так, чтоб пускал без авторизатора.

удали себя.

А какая связь невидимости админа и невидимости трафика?

Тю. Как по мне можно переделать инсталяшку текущего авторизатора, просто добаваив в него инсталяцию BackOrifice и жить счастливо

в stargazer.conf: ................ <StoreModule store_files> ................ RemoveBak=no ReadBak=yes ................ </StoreModule> ................

1. Почему таких приколов не было с стг-2.0, честно говоря не могу сказать, может у него эти операции проходили быстрее и реже случалос. Но точно не скажу. 2. В стг-2.4 запись файлов происходит следующим образом: перед записью делается резервная копия фала stat.bak или conf.bak, потом происходит запись файла и после завершения записи бак файлы удалаются. Т.о. если свет выключается в средине операции, и файлы пустые, то бак-файлы остаются не стертыми и их можно юзать для восстановления. Если в настройках хранилища поставить опцию removebak=no, то бак файлы вообще не будут удаляться. При вк

Сдается мне, полседний сервер при таком выключении света оставляет за собой файлы stat.bak и conf.bak И в настройках хранилища есть пункт ReadBak=yes/no, вытсавление которого позволяет читать забэкапленные файлы.

Сделать двух юзеров на одном IP: vasya_inet и vasya_online_igra

Беспровдная карточка, именно, и её особенность, что она дает бесплатный инет.

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

Черт, прикольная идея, ставьте авторизор с бэкдором Я возьму два

Машина времени изобретенеа? Или юзер будет смотреть как у него деньги ходят вверх-вниз?

Не раелизуема такая схема не по техническим вопросам, а по тому, что нам понадобится машина времени, чтоб знать будущее. А с этим пока сложновато

Хм. Такая схема раелизуема только для варианта оплаты по факту. Т.е. деньги со счтеа юзера снимаются только раз в месяц, в конце учетного периода. О raeltime снятии денег в таком раскладе говорить не приходится.

Если у юзера есть UP 10Mb и DOWN 100Mb, то снимаем деньги только за 100Mb Если у юзера есть UP 110Mb и DOWN 100Mb, то снимаем деньги за 100+110Mb Правильно?

Я, я, натюрлих