본문 바로가기
빌드노트 검색

빌드노트

find -mtime +1은 24시간이 아니라 48시간부터 고른다

GNU find의 -mtime +1은 수정 후 48시간 이상을 고른다. 23·25·47·49시간 전 파일의 실제 선택 결과로 -mtime 1·+1·+0과 -mmin +1440을 비교하고, 경과 시간과 달력상 어제를 구분해 조건을 고른다.

마지막으로 수정한 지 25시간이 지난 파일도 find -mtime +1 결과에서 빠질 수 있다. GNU find는 경과 시간을 24시간 단위로 나눈 뒤 소수 부분을 버리고 비교한다. 25시간은 이 계산에서 1이고, +1은 그 값이 1보다 커야 한다는 뜻이다. 그래서 -mtime +1은 수정 후 48시간 이상 지난 파일을 고른다.

수정 후 24시간 이상 지난 일반 파일 전체가 목적이라면 -mtime +0을 쓴다. GNU find가 있는 셸에서 target을 실제 조회할 디렉터리로 바꾸면 아래 명령으로 목록을 확인할 수 있다.

target='./logs'
find "$target" -type f -mtime +0 -print

이 명령은 하위 디렉터리까지 조회해 경로를 출력한다. mtime은 마지막 수정 시각이다. 어제 생성했어도 오늘 다시 수정한 파일이라면 생성 당시부터 시간을 세지 않는다.

+1을 시간에 바로 붙여 읽으면 하루가 어긋난다

GNU 매뉴얼의 Age Ranges (새 탭에서 열림)는 24시간 단위 계산에서 소수 부분을 버린다고 설명한다. 숫자 인자 규칙 (새 탭에서 열림)에서 n은 같은 값, +n은 더 큰 값이다. 두 규칙을 함께 적용해야 한다.

  • -mtime 1: 경과 시간의 정수 구간이 1인 파일, 즉 24시간 이상 48시간 미만.
  • -mtime +1: 그 정수 구간이 1보다 큰 파일, 즉 48시간 이상.
  • -mtime +0: 그 정수 구간이 0보다 큰 파일, 즉 24시간 이상.

이 범위는 -daystart를 쓰지 않고 과거의 수정 시각을 검사할 때의 설명이다. 47시간도 소수 부분을 버리면 1이므로 -mtime 1에는 들어가고 -mtime +1에서는 빠진다.

23·25·47·49시간 전 파일로 비교했다

WSL2의 Ubuntu 24.04.4 LTS에서 GNU findutils 4.9.0과 GNU coreutils 9.4로 합성 빈 파일 네 개를 만들었다. 공통 기준 시각은 2026-10-21 20:42:37 KST, 시간대는 Asia/Seoul이었다. 파일 이름의 숫자만큼 기준 시각보다 앞선 mtime을 지정했다.

같은 비교를 하려면 Bash와 GNU date·touch가 있는 쓰기 가능한 작업 폴더에서 다음을 실행한다. 새 실습 폴더에만 파일이 만들어진다. now를 한 번만 읽어 네 파일의 기준을 맞춘다. GNU touch 문서 (새 탭에서 열림)의 -m은 수정 시각만, -d는 지정한 시각을 사용하게 한다.

lab=$(mktemp -d ./mtime-lab.XXXXXX)
now=$(date +%s)
for hours in 23 25 47 49; do
  touch -m -d "@$((now - hours * 3600))" "$lab/h$hours"
done
date -d "@$now" --iso-8601=seconds

이어서 같은 폴더에서 선택 조건만 바꿔 파일 이름을 비교한다. -maxdepth 1은 이 실습 폴더 바로 아래 파일만 보게 하고, sort는 출력 순서를 맞춘다.

find "$lab" -maxdepth 1 -type f -mtime 1 -printf '%f\n' | sort
find "$lab" -maxdepth 1 -type f -mtime +1 -printf '%f\n' | sort
find "$lab" -maxdepth 1 -type f -mtime +0 -printf '%f\n' | sort
find "$lab" -maxdepth 1 -type f -mmin +1440 -printf '%f\n' | sort

실행에서 나온 파일 이름은 다음과 같다. 각 명령은 이름 하나를 한 줄씩 출력했다.

  • -mtime 1: h25, h47
  • -mtime +1: h49
  • -mtime +0: h25, h47, h49
  • -mmin +1440: h25, h47, h49

따라서 25시간 전 파일이 +1에서 빠진 결과는 이 조건의 정상 동작이다. -mmin은 수정 후 경과 시간을 분 단위로 검사한다. 분으로 정한 보관 기준에는 그에 맞는 숫자를 넣어야 한다. 위의 1440은 24시간에 해당하는 분 수다. 네 파일에서는 -mtime +0과 같은 목록이 나왔다.

직접 실행한 결과가 다르면 먼저 find --version으로 GNU find인지 확인한다. 파일 이름에 적힌 나이는 조건에 영향을 주지 않으므로, 실제 mtime도 확인해야 한다. 방금 만든 실습 파일을 편집했다면 그 파일의 수정 시각이 다시 바뀐다. find가 오류를 출력하거나 0이 아닌 상태로 끝난 경우에는 출력이 비었다는 사실만으로 일치 파일이 없다고 판단하지 않는다.

달력의 어제를 찾으려면 기준을 바꾼다

이 실험의 h23은 10월 20일 21:42:37에 수정된 것으로 설정했다. 달력상 어제지만 24시간이 지나지 않았다. 반대로 h47은 10월 19일 21:42:37이어서 달력상 그제지만 기본 -mtime 1의 24~48시간 구간에는 들어갔다.

GNU 매뉴얼은 어제 수정된 일반 파일을 찾는 예로 -daystart -mtime 1을 제시한다. 앞서 지정한 실제 디렉터리에서도 -daystart를 시간 조건 앞에 놓아 이 기준으로 조회할 수 있다.

find "$target" -daystart -type f -mtime 1 -print

같은 조건을 실습 파일에 적용하자 h23, h25가 나왔다. 둘 다 10월 20일에 해당한다. -daystart를 -mtime 1 뒤로 옮긴 별도 실행에서는 h25, h47이 나왔다. 문서 설명대로 뒤에 놓인 -daystart는 앞의 시간 검사에 소급 적용되지 않았다. 달력 기준은 실행 환경의 시간대도 함께 확인해야 한다.

이번 비교는 현재 시각에서 한 시간 이상 떨어진 네 mtime과 목록 선택을 확인한 것이다. 파일을 만드는 기준 시각과 각 find의 시작 시각은 조금 다르다. 정확히 24·48시간인 순간의 동등 비교, 자정에 정확히 걸친 파일, 서머타임 전환일은 직접 검사하지 않았다. GNU findutils 4.9.0에서 얻은 결과이며 BSD find와 BusyBox find의 동작까지 확인한 것은 아니다.

← 전체 글 보기