vop

В общем, я хотел предложить пару идей, а не спорить, кто тут чукча. Если идеи не интересуют, то зачем я буду что-то доказывать?

Честно говоря, я не готов продолжать дальше, ибо обсуждаем уже не вариант алгоритма, который позволит данным не пропадать, а начинаем спорить с POSIX... Я пасс... POSIX требует, что бы эта функция была атомарная. Ее реализация под линуксом и фрей является атомарной. The rename function is specified in the stdio.h library header file in C and the cstdio header in C++. It is specified in ANSI C. In POSIX, rename will fail (with EXDEV) if the old and new names are on different mounted file systems. On Linux, if a call to rename succeeds it is [b]guaranteed to have been atomic[/b] from the

С рождения у тебя на каждую величину были отдельные файлики - ip, cash, pswd, на каждый счетчик и т.д. И для каждого счетчика тоже были отдельные файлы. Вот так и получалось, что при инициализации каждого клиента, старгейзер читал по 15 файлов. Вот из моего старого конвертора. loadd - это типа трафик по Днепру Тут не все файлы, а только те, которые нужны были для сбора статистики на верхний уровень. #define BILLI_FILE_IP BILLI_HOME_DIR"/%s/ip" #define BILLI_FILE_LOADI BILLI_HOME_DIR"/%s/loadi" #define BILLI_FILE_LOADD BILLI_HOME_DIR"/%s/loadd" #define BILLI_FILE_LOADE BILLI_HOM

Вот этого делать нельзя!!! Нельзя переписывать файл по живому. Вообще, нельзя открывать ни один рабочий файл на запись. Хоть кто-нибудь читал, что я там накарябал? Новый файл создается отдельно. На момент выполнения rename уже никто никуда не переписывается и не двигается. Одной операцией запмисывается указатель на новый массив данных.

Возможно, тебе сказать трудно. Я Борису об этом 5 лет назад говорил. Тогда еще не было файлов stat в базе старгейзера. Но опасность исчезновения данных уже были заложены заранее не совсем разумной работой с данными. В общем, на этом и закончим. При чем тут mv - не знаю.

If the rename() function fails for any reason other than [EIO], any file named by new shall be unaffected. Перевожу на русский толковый - что бы ни случилось (кроме физической поломки винта), любой из двух файлов (старый или новый) должен остаться на новом месте, причем, остаться целкой. Так-что нет никакого момента "когда старый удален" и так далее. Это ГАРАНТИЯ функции rename() по стандарту POSIX, который требует атомарной реализации этой функции Она не уменьшает вероятность пропажи файла, а ИСКЛЮЧАЕТ вообще их пропажу. Ой, сомневаюсь, что тебе поможет журналируемая fs. Мало

Если не ошибаюсь, это было где-то в 2002 году. Я тогда много своих соображений тебе высказывал. В том числе и по переводу авторизатора с tcp протокола на udp, или, например, из критичных на мой взгляд вопросов - переход на целочисленную арифметику и накопительный подсчет данных. В общем, много тогда говорили - возможно что и забылось уже. Давай лучше к данному вопросу, который мучает умы уже много времени. Правила гарантированного сохранения данных при работе с файлами очень простые. Есть несколько разных вариантов. Это конечно правильно ты мыслишь с разными bak-файлами, но не совсем прави

Так кто должен написать? Разве не Борис? Или просто надо обсудить алгоритм и принципы гарантированной записи данных в файл. Я могу предложить один из вариантов, который я рассказывал Борису лет 5 назад. Какая проблема-то?

Либо, наконец, написать нормальную работу с файлами без всех этих подпорок Ну не сложно же ведь!

Поделитесь грибами Вообще-то странная схема начисления оплаты. Имейте ввиду, что вы получаете скачок начисления в середине месяца, если вдруг исходящий трафик превысит входящий. Реализовать такое можно и в реалтайме, но я сомневаюсь, что кто-то возмется это делать.

Какого именно клиент-банка?

А какое именно мнение интересует? Ибо "да" и "нет" к мнению сложно отнести. P.S. Держим, а как же?

root в юниксоподобных системах определяется не словесным идентификатором (root), а номером uid`а = 0.

Там можно не только по маскам задавать цейпер, но и маркировать пакеты по разным критериям. Смотри опцию --mark iptables

Пример такого скрипта (именно, пример): https://topola.unity.net/filef/rc/taweb-0.05.29-rc5.tar.gz Надо зарегистрироваться. Регистрация бесплатная и без подтверждения. После этого определяешься с источником, что именно хочешь показывать, определяешься со страничками, которые надо тянуть, возможно, апдейтишь скрипт, и ставишь его на локальный сервер. Юзер логинистся к локальной странице - а скрипт к удаленному серверу. Еще один вариант - с помощью команды wget деклаешь локальное зеркало выбранной страницы.

Поставь проксирующий скрипт на какой-нибудь гисметео.

Очень сильно все навалено в кучу, нет четкой струкутризации. Вот над этим надо бы поработать. P.S. Ну и забано, что заказывать переход на новый тариф можно только один раз в месяц...

Как?

Как не бывает хорошего ресторана без шеф-повара, так и не бывает хорошего провайдера без админа...

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

Ты просил штатно, или "как-нибудь"? Если как-нибудь - бери любую утилиту-енкриптор. Или сам напиши - не сложно. Вот если "штатно", то де-факто штатно - это openssl.

Это будет более, чем корректно.

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

Просто любопытно стало - а как он может помешать смотреть онлайн?

Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно.