Hello! > Я же говорю: "насколько тупой скрипт бэкапа", а не "насколько тупая > программа"... Скрипту бэкапа вполне достаточно знать про возможность не > трогать atime, поскольку по смыслу его операция не является доступом к > файлу, она является _созданием его резервной копии_. > > AP> А использование последнего времени доступа предполагает, что > AP> программа запущена на однопользовательской машине, > > Это неверно. Чистить ~/tmp (нифига не включаемую в бэкап, поскольку она > tmp по смыслу) по atime - самое оно. "Мужик, ты вот тут парочку типа > временных файлов месяц не смотрел _никакой_ программой - они тебе точно > нужны?" Или наоборот, "мужик, тут у тебя в tmp файл не менялся два > месяца, а смотрелся вчера - может, он таки тебе нужен, и мы его положим > куда-нибудь, где он бэкапиться будет?"
Помилуйте, но откуда в /tmp такой мусор? $ uptime 18:04:15 up 247 days $ ls /tmp/|wc -l 33 Что там чистить-то? Ну, на ноуте/десктопе малость поболее может быть мусора, но эти машинки обычно пару раз в месяц да перезагружают, а некоторые пользователи даже чаще, так что само чистится. А писать серверный софт с устраиванием свалки из временных файлов я уже зарекся. Видел немало софта, который эту свалку таки устраивает, например, если вы используете php-based soft, то atime вам нужен. Впрочем, то, что хранит mutt, вроде как раз не относится к временным файлам. > > AP> что собственно противоречит идеологии линукса, как я ее понимаю. > > Могу только порекомендовать подумать над идеей расширить свое понимание > идеологии линукса... У тебя это вроде бы неплохо получалось... При наличии аргументов, чтоб было над чем думать. Пока что вижу только проблемы с криво написанным софтом, который устраивает свалку и приходится с этим как-то бороться. Кто создал файл, тот и должен его удалить, если не удалил - значит, нужный процесс помер преждевременно и надо еще разобраться, что случилось. Best regards, Alexey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
