удаление файлов после 2-х дней

[Skyb]

создается архив вот такой командой

Код: Выделить всё

zip -r -9 zip.`date +%Y-%m-%d_%Hh%Mm`.zip zip/

файл архива принимает вид
zip.2011-08-19_14h50m.zip
как удалить этот файл по истечению 2-х дней?
тоесть файлы создаются ежедневно, неохота плодить, как удалить?

[rm_]

Код: Выделить всё

find -name \*.zip -not -newermt "2 days ago" -execdir rm "{}" \;

Как-то так. И ещё

Код: Выделить всё

man find

[Poor Fred]

Как вариант:

Код: Выделить всё

date --date="2 days ago"
Срд Авг 17 13:07:38 NOVT 2011

[drBatty]

как удалить этот файл по истечению 2-х дней?

Код: Выделить всё

find . -ctime +2 -delete

[watashiwa_daredeska]

Код: Выделить всё

find . -ctime +2 -delete

ctime в данном случае — не очень подходящий параметр. mtime и то более подходящий.

[drBatty]

-ctime n
File's status was last changed n*24 hours ago. See the comments for -atime to understand how rounding affects the interpretation of file sta‐
tus change times.


-delete
Delete files; true if removal succeeded. If the removal failed, an error message is issued. If -delete fails, find's exit status will be
nonzero (when it eventually exits). Use of -delete automatically turns on the -depth option.

Warnings: Don't forget that the find command line is evaluated as an expression, so putting -delete first will make find try to delete every‐
thing below the starting points you specified. When testing a find command line that you later intend to use with -delete, you should explic‐
itly specify -depth in order to avoid later surprises. Because -delete implies -depth, you cannot usefully use -prune and -delete together.

ctime в данном случае — не очень подходящий параметр. mtime и то более подходящий.

не знаю. скорее всего одинаково.
но ctime ИМХО ближе по смыслу к "дате создания".

[drBatty]

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

[t.t]

ctime в данном случае — не очень подходящий параметр. mtime и то более подходящий.

не знаю. скорее всего одинаково.
но ctime ИМХО ближе по смыслу к "дате создания".

Не ближе. ctime это время изменения мета-информации файла. Оно меняется ещё чаще, чем mtime.

[drBatty]

Не ближе. ctime это время изменения мета-информации файла. Оно меняется ещё чаще, чем mtime.

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

[IMB]

Код: Выделить всё

LOGROTATE(8)             System Administrator's Manual            LOGROTATE(8)

NAME
       logrotate - rotates, compresses, and mails system logs

SYNOPSIS
       logrotate [-dv] [-f|--force] [-s|--state file] config_file ..

DESCRIPTION
       logrotate  is  designed to ease administration of systems that generate
       large numbers of log files.  It allows automatic rotation, compression,
       removal, and mailing of log files.  Each log file may be handled daily,
       weekly, monthly, or when it grows too large.
....................................................
daily  Log files are rotated every day.
.......................................
 rotate count
              Log files are rotated count times before being removed or mailed
              to the address specified in a mail directive. If count is 0, old
              versions are removed rather than rotated.

Правда придётся изменить название файлов.

[drBatty]

IMB
?

[sash-kan]

IMB
?

отвечаю вместо IMB: это намёк на изящное решение·

[drBatty]

это намёк на изящное решение·

а... да...
теоретически конечно возможно наверное... вот только зачем? программа-то совсем для другого... Хотя можно лить весь бекап в один поток, а logrotate будет его резать на куски, и удалять лишние старые кусочки. Может в некоторых случаях это хорошее решение (если надо бекапить например 1 файл в 10К, который меняется 100500 раз в день).

[sash-kan]

программа-то совсем для другого

что значит «другого»?

Хотя можно лить весь бекап в один поток, а logrotate будет его резать на куски, и удалять лишние старые кусочки

перечитайте условие·
раз в сутки кто-то/что-то создаёт файл·
надо его раз в сутки переименовать, переименованный ещё через сутки опять переименовать, повторить нужное количество раз·
по достижении этого количества самый старый файл удалить·
именно так и действует logrotate·
конечно, он ещё всякими фенечками обвешан· например, может выполнить указанные команды до и после переименования «базового» файла· т.е. даже вызов команды, упомянутой топик-стартером, можно поручить logrotate-у·

[drBatty]

надо его раз в сутки переименовать, переименованный ещё через сутки опять переименовать, повторить нужное количество раз·

в условии никто не говорил про переименование. да и с бекапами так делать страшновато - зачем их переименовывать с конца?
3->4
2->3
1->2
->1

конечно, он ещё всякими фенечками обвешан·

например может переименовать бекап не всегда, а тогда, когда он >100Мб. Правда я не понимаю, зачем это надо ;)
ну конечно можно. Если find . -ctime +2 -delete запрещена Законом и Конституцией :)

[sash-kan]

в условии никто не говорил про переименование

да, вы правы· слово «переименование» не упомянуто· но суть переименования изложена — каждый файл с уникальным именем, зависящим от даты его создания· ежесуточная инкрементация счётчика в имени выполняет ровно ту же функцию·

да и с бекапами так делать страшновато

от переименования бэкапы портятся?

p.s. кстати, из «фенечек» может в данном случае пригодиться возможность сжатия «базового» файла·
т.е. само архивирование исходных данных не будет затормаживаться одновременным сжатием·
что позволяет увеличить шансы на то, что в архиве будет более консистентная картина·
естественно, это можно сделать и без logrotate· logrotate — всего лишь «ещё один путь, которым можно пойти»·

[drBatty]

слово «переименование» не упомянуто· но суть переименования изложена — каждый файл с уникальным именем, зависящим от даты его создания· ежесуточная инкрементация счётчика в имени выполняет ровно ту же функцию·

ну не знаю. что там ТСу надо - мне неведомо. Устроят-ли его файлы backup.1, backup.2 вместо

zip.2011-08-19_14h50m.zip

...зависит от ТС.

от переименования бэкапы портятся?

вообще-то переименование == перемещение == удаление.
правда тут файлы гарантированно на одной ФС, и никакого удаления не будет...
всё равно страшно (:

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

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

logrotate — всего лишь «ещё один путь, которым можно пойти»·

угу. В конце концов вы меня таки убедили. Что неудивительно, ведь logrotate == специализированная программа для бекапа (логов).

[Skyb]

Попробовал - чета не взлетело, нада разбираться. Думал по поводу логротейта.

Правда придётся изменить название файлов.

только вот этого не понял. У файла должно на конце быть *.log ???

[drBatty]

только вот этого не понял. У файла должно на конце быть *.log ???

не обязательно. просто нумероваться они будут не датой, а так:
backup.zip
backup.zip.1
backup.zip,2
и т.д.
Причём упаковку удобно доверить самой logrotate.

[t.t]

Не ближе. ctime это время изменения мета-информации файла. Оно меняется ещё чаще, чем mtime.

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

Может быть, стоило проверить, прежде чем говорить?

Код: Выделить всё

root@tt:/var/log# find -type f | while read f; do mt=$(ls -l --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -gt $ct ] && echo $ct $mt $f; done
root@tt:/var/log# find -type f | while read f; do mt=$(ls -l --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -lt $ct ] && echo $ct $mt $f; done | wc -l
83

[t.t]

А файлы, у которых ctime меняется чаще mtime - мне такой пример и не привести с ходу...

Вот Вам пример сходу:

Код: Выделить всё

t $ ls -dl .
drwxr-x--- 79 t t 4096 Авг 21 10:48 .
t $ ls -dlc .
drwxr-x--- 79 t t 4096 Авг 21 10:48 .
t $ chmod 700 .
t $ ls -dl .
drwx------ 79 t t 4096 Авг 21 10:48 .
t $ ls -dlc .
drwx------ 79 t t 4096 Авг 22 14:12 .

[t.t]

Код: Выделить всё

root@tt:/var/log# find -type f | while read f; do mt=$(ls -l --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -gt $ct ] && echo $ct $mt $f; done
root@tt:/var/log# find -type f | while read f; do mt=$(ls -l --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -lt $ct ] && echo $ct $mt $f; done | wc -l
83

Кстати, для статистики:

Код: Выделить всё

$ sudo find /var/log/ -type f | wc -l
129

[drBatty]

Может быть, стоило проверить, прежде чем говорить?

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

Вот Вам пример сходу:

контр-пример:

$

doc@dt:~$ stat . Файл: «.» Размер: 12288 Блоков: 24 Блок В/В: 4096 каталог Устройство: 807h/2055d Inode: 1042433 Ссылки: 71 Доступ: (0711/drwx--x--x) Uid: ( 1000/ doc) Gid: ( 100/ users) Доступ: 2011-08-24 12:20:43.959037799 +0400 Модифицирован: 2011-08-24 12:24:32.988573439 +0400 Изменён: 2011-08-24 12:24:32.988573439 +0400 Создан: -

ЧЯДНТ?

[t.t]

Может быть, стоило проверить, прежде чем говорить?

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

При чём здесь logrotate? Она Вас чем-то беспокоит? Хорошо, смотрите:

Код: Выделить всё

root@tt:/etc# find -type f | while read f; do mt=$(ls -l --time-style 'long-iso' $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -gt $ct ] && echo $ct $mt $f; done
root@tt:/etc# find -type f | while read f; do mt=$(ls -l --time-style 'long-iso' $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -lt $ct ] && echo $ct $mt $f; done | wc -l
1036
root@tt:/etc# find -type f | wc -l
3679

Код: Выделить всё

root@tt:/usr/bin# find -type f | while read f; do mt=$(ls -l --time-style 'long-iso' $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -gt $ct ] && echo $ct $mt $f; done
root@tt:/usr/bin# find -type f | while read f; do mt=$(ls -l --time-style 'long-iso' $f | awk '{print $6 $7}' | tr -d :-); ct=$(ls -lc --time-style long-iso $f | awk '{print $6 $7}' | tr -d :-); [ $mt -lt $ct ] && echo $ct $mt $f; done | wc -l
1263
root@tt:/usr/bin# find -type f | wc -l
1263

Достаточно?

Вот Вам пример сходу:

контр-пример:

$

doc@dt:~$ stat . Файл: «.» Размер: 12288 Блоков: 24 Блок В/В: 4096 каталог Устройство: 807h/2055d Inode: 1042433 Ссылки: 71 Доступ: (0711/drwx--x--x) Uid: ( 1000/ doc) Gid: ( 100/ users) Доступ: 2011-08-24 12:20:43.959037799 +0400 Модифицирован: 2011-08-24 12:24:32.988573439 +0400 Изменён: 2011-08-24 12:24:32.988573439 +0400 Создан: -

ЧЯДНТ?

Это не контр-пример. Здесь ctime и mtime совпадают. Ещё раз: при изменении mtime _всегда_ меняется и ctime. Обратное неверно: можно изменить ctime, не изменив mtime. Я Вам продемонстрировал, как это можно сделать; привёл статистику, подтверждающую, что mtime часто бывает меньше, чем ctime, но никогда не бывает больше. Вам всего этого недостаточно?

[drBatty]

Достаточно?

не. мне лень разбирать ваши одностроки. пишите по-русски.

Это не контр-пример. Здесь ctime и mtime совпадают.

А файлы, у которых ctime меняется чаще mtime - мне такой пример и не привести с ходу...

я не говорил "реже". я говорил "не чаще".

Ещё раз: при изменении mtime _всегда_ меняется и ctime.

ещё раз - где я с этим спорил?

Я Вам продемонстрировал, как это можно сделать; привёл статистику, подтверждающую, что mtime часто бывает меньше, чем ctime, но никогда не бывает больше. Вам всего этого недостаточно?

конечно нет. я ведь с этим и не спорил. ну бывает, ну и что это доказывает? вернитесь к изначальному утверждению.

привёл статистику, подтверждающую, что mtime часто бывает меньше

да ну?

[/dev/random]

привёл статистику, подтверждающую, что mtime часто бывает меньше

да ну?

Shell

$ echo $(( 100 * $(find ~ -xdev -printf '%C@ %T@ %p\n' | while read a b c; do [ "$a" != "$b" ] && echo "$c"; done | wc -l) / $(find ~ -xdev | wc -l) ))% 26%

По-моему, достаточно часто.

[drBatty]

/dev/random
Ну. Четверть ваших файлов имеет штамп ctime != mtime. Это доказывает, что искать старые бекапы надо по mtime? Какой сакральный смысл в приведённых вами цифрах?

[/dev/random]

/dev/random
Ну. Четверть ваших файлов имеет штамп ctime != mtime. Это доказывает, что искать старые бекапы надо по mtime? Какой сакральный смысл в приведённых вами цифрах?

Это доказывает, "что mtime часто бывает меньше". Вы пытались опровергнуть выделенное слово.

[drBatty]

Это доказывает, "что mtime часто бывает меньше". Вы пытались опровергнуть выделенное слово.

я пытаюсь вам доказать, что в контексте данной темы это не важно.
в каких-то других контекстах (в ваших 26%) это может быть и играет какую-то роль, но эти ваши 26% просто мимо кассы в данном конкретном случае. Да и вообще - это не корректно - считать процентами или штуками. Пример logrotate это доказывает - у вас 10 логов, и 100 файлов с их бекапом. Но ситуаций-то две:

1. логи,
2. бекапы логов.

Но по вашему получается 90%. "средняя температура в палате 36.7"...

И да, объясните мне наконец, какой смысл менять ctime бекапов без смены mtime? Ну конечно, если это не делает та-же logrotate (которая переименовывает файлы со старыми бекапами).

[t.t]

drBatty, я уже по два раза Вам объяснил и "одностроками", и "по-русски". Ваше нежелание видеть очевидное даже после того, как я его специально для Вас препарировал, -- это сугубо Ваша личная проблема. Как и Ваша неспособность признать собственную неправоту.