[Comm] Kmail. Серьезная бага. sim

[Comm] Kmail. Серьезная бага. sim

[@ 2008-03-20 2:53 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-20 3:51 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-20 9:19 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-20 10:55 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 8:51 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 8:53 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 9:10 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 9:22 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 10:12 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-21 19:55 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-24 14:46 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[@ 2008-03-24 15:14 UTC (permalink / raw)]

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

On Monday 24 March 2008, Анатолий Акатьев wrote:

[...]
> Линукс либо будет юзер френдли
Будет-будет. В KDE4 появилась утилита разчистки места.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim [JT]

[Maxim Tyurin]

Анатолий Акатьев writes:

> В сообщении от Monday 24 March 2008 19:46:11 Maxim Tyurin написал(а):
>> Анатолий Акатьев writes:
>> >> Andrey Rahmatullin пишет:
>> >> > """Да собственно тут дело даже не в мониторинге.
>> >> > Глазом не успеешь глянуть как твои данные похеряны.""
>> >>
>> >> Тут глазом глядеть нужно заранее, когда 80%++. Благо объем дисков
>> >> позволяет ;)
>> >
>> > Вы мне покажите юзвера который смотрит за местом (системные сообщения
>> > читает, лог смотрит, man курит) ???
>>
>> Любой который не прочитал письмо от repquota и у которого по истечении
>> grace time потерло файлы. После этого читают и смотрят за местом.
>
> Предлагаю расстреливать юзера сразу же. Так проще - потом не повторит косячных 
> действий. 
> Господа. Линукс либо будет юзер френдли и будет популярность набирать
> Либо так и останется для любителей раскрашивать белки глаз в красный цвет.

А расскажите каким местом более юзер френдли "самая интуитивно
понятная система"? Там квоты ведут себя аналогично.

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

P.S. У нас тут недавно такой "простой водитель" которому не надо
смотреть на приборы встал на мосту потому что бензин закончился.
И почему-то ни у кого сочувствия не вызвал.
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

Re: [Comm] Kmail. Серьезная бага. sim

[Konstantin S. Uvarin]

On Thursday 20 March 2008 05:53:16 Анатолий Акатьев wrote:
> По хорошему то нужно подвесить процесс в ALD который должен следить за
> заполнением разделов и информировать об этом юзверей и останавливать
> приложения. Иначе представляете потерю данных в офисе!!!

Не такая уж плохая мысль, запихнуть скрипт в cron.daily, который будет 
смотреть df и по результатам писать пользователям слёзные письма. Правда, 
обычно как раз пользователи их не читают, а место кончается. И кроме того, я 
отчетливо понимаю, что не один такой умный. 

У меня, правда, ещё есть (бредовая) идея создать что-то типа backyard

В /home/ дейстивтельно важная информация + настройки, там делается ежедневный 
бэкап и пр. 

В /yard/ всякий хлам из интернета, кино-музыка и проч. То, что жалко 
выбросить, но не страшно потерять. 

Однако на установление такого порядка (если оно вообще разумно) уйдет 
десятилетие, а кроме того, не факт что пользователи не будут схоранять музыку 
в /home, а работу в /yard. 

-- 
Konstantin S. Uvarin
Прощёлкав Первое мая, измаялся партизан Семён. Электричество завёл --
и к Бауману в Курск, революцию делать.

Re: [Comm] Kmail. Серьезная бага. sim

[Konstantin S. Uvarin]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]


> Не такая уж плохая мысль, запихнуть скрипт в cron.daily, который будет
> смотреть df и по результатам писать пользователям слёзные письма. 

Вот, накатал простенький скрипт. Хотя, по-моему, их таких примерно столько же, 
сколько и админов. 

Никаких входных параметров не знает, просто тупо смотрит всех пользователей с 
id>=$HUMAN и шлет им письмо, если в их $HOME меньше $THRESH свободного места. 

-- 
Konstantin S. Uvarin
"Birthdays are good for you: the more you have, the longer you live "

[-- Attachment #2: fsmon.sh --]
[-- Type: application/x-shellscript, Size: 522 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Алексей Синицын]

20.03.08, Konstantin S. Uvarin<khedin@mail.ru> написал(а):
>
>  > Не такая уж плохая мысль, запихнуть скрипт в cron.daily, который будет
>  > смотреть df и по результатам писать пользователям слёзные письма.
>
>
> Вот, накатал простенький скрипт. Хотя, по-моему, их таких примерно столько же,
>  сколько и админов.
>
>  Никаких входных параметров не знает, просто тупо смотрит всех пользователей с
>  id>=$HUMAN и шлет им письмо, если в их $HOME меньше $THRESH свободного места.
>

 Наверно для этого нужно еще что-бы программа почты по умолчанию
собирала локальную. Все-ли почтовики это по умолчанию обучены делать?

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Thu, Mar 20, 2008 at 07:13:22PM +0300, Алексей Синицын wrote:
> >  id>=$HUMAN и шлет им письмо, если в их $HOME меньше $THRESH свободного места.
%
<stalker37> combr: Но на треш они изнеачально не похожи... Треш -это метла и
            иже с ними
<raorn> thresh - это совсем другой человек
%

>  Наверно для этого нужно еще что-бы программа почты по умолчанию
> собирала локальную. Все-ли почтовики это по умолчанию обучены делать?
А хоть какой-то обучен?
(а зря)

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Мастер достоин того, чтобы ради него купить DVD :)
		-- mithraen in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] [JT] Kmail. Серьезная бага. sim

[Konstantin S. Uvarin]

Приветствую! 

> >  Наверно для этого нужно еще что-бы программа почты по умолчанию
> > собирала локальную. Все-ли почтовики это по умолчанию обучены делать?
> А хоть какой-то обучен?
> (а зря)
Зря обучен или не обучен? Не совсем понятно из формулировки.

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

-- 
Konstantin S. Uvarin
"Мдурость"

Re: [Comm] [JT] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

On Mon, Mar 24, 2008 at 06:07:50PM +0300, Konstantin S. Uvarin wrote:
> > >  Наверно для этого нужно еще что-бы программа почты по умолчанию
> > > собирала локальную. Все-ли почтовики это по умолчанию обучены делать?
> > А хоть какой-то обучен?
> > (а зря)
> Зря обучен или не обучен? Не совсем понятно из формулировки.
Зря не обучен, конечно :)

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

On Thursday 20 March 2008, Andrey Rahmatullin wrote:

[...]
> А хоть какой-то обучен?
Да, KMail ;-)


-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

On Mon, Mar 24, 2008 at 06:09:29PM +0300, Sergey V Turchin wrote:
> > А хоть какой-то обучен?
> Да, KMail ;-)
Нене, а учётка такая создаётся по дефолту?

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Monday 24 March 2008, Andrey Rahmatullin wrote:
> On Mon, Mar 24, 2008 at 06:09:29PM +0300, Sergey V Turchin wrote:
> > > А хоть какой-то обучен?
> >
> > Да, KMail ;-)
>
> Нене, а учётка такая создаётся по дефолту?
Именно это и делается. И каждые 10 мин получение.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Анатолий Акатьев]

В сообщении от Thursday 20 March 2008 19:31:52 Konstantin S. Uvarin 
написал(а):
> > Не такая уж плохая мысль, запихнуть скрипт в cron.daily, который будет
> > смотреть df и по результатам писать пользователям слёзные письма.

Да собственно тут дело даже не в мониторинге.
Глазом не успеешь глянуть как твои данные похеряны. 
К сожалению не видно чтобы дистростроители чтонибудь сказали.


А заставлять (обучать, просить и т.п.) изеров бесполезно. Нужно чтобы этим 
рулила OS а не какие-то костыли.

Что скажут разрабы ALD ?




-- 
Доброе время суток!

С уважением Акатьев Анатолий.
Руководитель отдела внедрения.
тел.: 89509559748
icq : 190270141
www.master-system.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Thu, Mar 20, 2008 at 11:27:19PM +0500, Анатолий Акатьев wrote:
> Да собственно тут дело даже не в мониторинге.
> Глазом не успеешь глянуть как твои данные похеряны. 
И какое поведение вы предлагаете?
Ситуация: команда cp копирует 5 гигабайт в домашний раздел. Копирует
весьма быстро. Отвалится она только когда место уже кончится. 

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> >Может, в obsolete его сразу?
> И туда тоже !
Серьезно? Кудзу выкидываем?
		-- wrar in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Анатолий Акатьев]

В сообщении от Thursday 20 March 2008 23:32:10 Andrey Rahmatullin написал(а):
> она только когда место уже кончится

Ну вообще-то сначало нужно определить все ли достаточно для выполнения 
операции. В случае с cp  - проверить достаточно ли место там куда копируем 
или нет.

-- 
Доброе время суток!

С уважением Акатьев Анатолий.
Руководитель отдела внедрения.
тел.: 89509559748
icq : 190270141
www.master-system.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Thu, Mar 20, 2008 at 11:49:02PM +0500, Анатолий Акатьев wrote:
> Ну вообще-то сначало нужно определить все ли достаточно для выполнения 
> операции. В случае с cp  - проверить достаточно ли место там куда копируем 
> или нет.
Ответ номер 1: ок, возьмём не cp, а что-то, что заранее определить
записываемый объём не сможет.
Ответ номер 2: представьте два cp, параллельно копирующих 5 гб на раздел,
где свободно 6.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> > dia поломали?
> Поломали glib2 в новом релизе. Патч отправлен мантейнеру.
Мантейнер приложил полученный патч к glib2-2.5.6-alt2.
		-- aris in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Алексей Синицын]

20.03.08, Andrey Rahmatullin<wrar@altlinux.ru> написал(а):
> On Thu, Mar 20, 2008 at 11:49:02PM +0500, Анатолий Акатьев wrote:
>  > Ну вообще-то сначало нужно определить все ли достаточно для выполнения
>  > операции. В случае с cp  - проверить достаточно ли место там куда копируем
>  > или нет.
>
> Ответ номер 1: ок, возьмём не cp, а что-то, что заранее определить
>  записываемый объём не сможет.
>  Ответ номер 2: представьте два cp, параллельно копирующих 5 гб на раздел,
>  где свободно 6.
>

  Смоделировать крешевую ситуацию несложно.

  Интереснее подумать а что можно вообще сделать при такой постановке
вопроса. Действительно неочевидно.

  Постановка задачи наверно такова: При заполнении места на файловой
системе не должны теряться конфиги и почта (возможно так-же другие
важные данные небольшого объема).

  Первое что приходит - не начинать писать при заполненной ФС. Но
против этого нам аргумент что оно заполнится во время записи.

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

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Thursday 20 March 2008, Алексей Синицын wrote:

>   Первое что приходит - не начинать писать при заполненной ФС. Но
> против этого нам аргумент что оно заполнится во время записи.
 
При пересоздании файла писать надо в _новый_ файл. В случае успешной
записи удалять старый и переименовывать. Но это дело приложений. 
Возможно, для KDE достаточно переделать соответствующие функции в QT...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Fri, Mar 21, 2008 at 10:28:32AM +0400, Sergey wrote:
> При пересоздании файла писать надо в _новый_ файл.
А если это history?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Выпуск каждого дистрибутива -- это не только его подготовка, но, в
первую очередь, -- поддержка.
		-- aen in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Friday 21 March 2008, Andrey Rahmatullin wrote:

> On Fri, Mar 21, 2008 at 10:28:32AM +0400, Sergey wrote:

> > При пересоздании файла писать надо в _новый_ файл.

> А если это history?

Ну, во-первых, тоже можно так же, во-вторых, history вряд ли такой уж
важный файл, ну а в третьих, можно в приложениях выбор давать по типу
записи в файл - safe/unsafe. :-)

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Sun, Mar 23, 2008 at 01:06:09PM +0400, Sergey wrote:
> Ну, во-первых, тоже можно так же, во-вторых, history вряд ли такой уж
> важный файл
Вы ошибаетесь.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> хотелось бы, чтоб как-то поаккуратнее с зависимостями...
1. с зависимостями там все нормально
2. Господа, мы в Сизифе или где?
		-- shrek in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

Twas brillig at 13:06:09 23.03.2008 UTC+04 when Sergey did gyre and gimble:

 S> history вряд ли такой уж важный файл,

Вы ошибаетесь.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Анатолий Акатьев]

В сообщении от Sunday 23 March 2008 14:34:29 Mikhail Gusarov написал(а):
> Twas brillig at 13:06:09 23.03.2008 UTC+04 when Sergey did gyre and gimble:
>
>  S> history вряд ли такой уж важный файл,
>
> Вы ошибаетесь.

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

-- 
Доброе время суток!

С уважением Акатьев Анатолий.
Руководитель отдела внедрения.
тел.: 89509559748
icq : 190270141
www.master-system.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Sun, Mar 23, 2008 at 03:06:23PM +0500, Анатолий Акатьев wrote:
> Господа, давай не будем решать за пользователя - важно это или нет.
> Лично для меня - файл очень важный так как может пригодиться при разборе чьих 
> либо недоработок к примеру.
О чём и речь.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> twit ? а можно подброенее? Что это есть?
По русски говоря ignore :)
		-- mithraen in smoke-room@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Twas brillig at 15:06:23 23.03.2008 UTC+05 when Анатолий Акатьев did gyre and gimble:

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

О чём и речь.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Sunday 23 March 2008, Mikhail Gusarov wrote:

>  АА> Господа, давай не будем решать за пользователя - важно это или нет.
>  АА> Лично для меня - файл очень важный так как может пригодиться при разборе чьих 
>  АА> либо недоработок к примеру.
> 
> О чём и речь.

Хуже, чем сейчас, всё равно не будет.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Алексей Синицын]

21.03.08, Sergey<a_s_y@sama.ru> написал(а):
> On Thursday 20 March 2008, Алексей Синицын wrote:
>
>  >   Первое что приходит - не начинать писать при заполненной ФС. Но
>  > против этого нам аргумент что оно заполнится во время записи.
>
>
> При пересоздании файла писать надо в _новый_ файл. В случае успешной
>  записи удалять старый и переименовывать. Но это дело приложений.
>  Возможно, для KDE достаточно переделать соответствующие функции в QT...
>

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

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

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

 Возможно описанное - это утопия.

Re: [Comm] Kmail. Серьезная бага. sim

[Damir Shayhutdinov]

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

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Friday 21 March 2008, Damir Shayhutdinov wrote:

> >  файловой системе увеличить размер файла. И потом писать уже в
> >  существующий файл, в хвост, в пустое зарезервированное место
> >  (возможна-ли фрагментация внутри файла на случай записи в середину?).

> Специально для этого в современных ядрах сделали вызов fallocate.
 
О, даже так ? Тогда можно стразу уже баги развешивать на соответствующие
компоненты. :-) Только, наверное, тут надо в первоисточнике...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Friday 21 March 2008, Алексей Синицын wrote:

> >  При пересоздании файла писать надо в _новый_ файл. В случае успешной
> >  записи удалять старый и переименовывать. Но это дело приложений.
> >  Возможно, для KDE достаточно переделать соответствующие функции в QT...
> >
> 
>   Прежде всего это плохо применимо к большим файлам (в которые
> дописывается часть). Использование файловой системы начинает резко
> скакать вырастая и уменьшаясь неоправданно (появляются и исчезают
> большие файлы, многократная перезапись данных, нагрузка ни привод и на
> систему). 

Ничего подобного. Зачем это делать постоянно ? Я только про отработку
функции save. 

>  Где размещать этот механизм? Видимо лучше всего разместить это один
> раз и не обучать каждую программу в отдельности, то есть в механизм
> работы с файловой системой в ядре.

Нет, в ядре это лишнее совершенно. Это беда уровня приложений. Вот QT,
например, в плане записи конфигов и т.п. - это самое место. Аналогично,
видимо, gtk...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Thursday 20 March 2008, Анатолий Акатьев wrote:

> А заставлять (обучать, просить и т.п.) изеров бесполезно. Нужно чтобы этим 
> рулила OS а не какие-то костыли.
 
ОС этим рулить не может - она не отвечает за отдельно взятое приложение...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[A.Kitouwaykin]

On Thu, 20 Mar 2008 17:31:52 +0300
Konstantin S. Uvarin wrote:

> 
> > Не такая уж плохая мысль, запихнуть скрипт в cron.daily, который будет
> > смотреть df и по результатам писать пользователям слёзные письма. 
> 
> Вот, накатал простенький скрипт. Хотя, по-моему, их таких примерно столько же, 
> сколько и админов. 
> 

$ crontab -l
13 13,17 * * * df | grep '9.\%\|100\%'

:)


-- 
Китайкин Анатолий Константинович
ОАО "Радиоавионика", СПб

Re: [Comm] Kmail. Серьезная бага. sim

[Sergey]

On Thursday 20 March 2008, Анатолий Акатьев wrote:

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

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Kmail. Серьезная бага. sim

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Fri, Mar 21, 2008 at 10:23:13AM +0400, Sergey wrote:
> > По хорошему то нужно подвесить процесс в ALD который должен следить за 
> > заполнением разделов и информировать об этом юзверей и останавливать 
> > приложения. Иначе представляете потерю данных в офисе!!!
> Вообще, надо репортить баги на приложения, которые теряют данные при
> заполнении диска...
Угу.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Можно ли программно установить uid процесса = 0, если приложение
> запущено без флажка set user ID on execution, от простого пользователя,
> и без помощи программ типа su, sudo и т.п. приложений?????
Если вы найдёте способ, сообщите нам, пожалуйста, и мы немедленно выпустим
security update.
		-- voins in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]