파일 이름 변경을 감지하고 이전 파일 이름과 새 파일 이름을 얻는 안정적인 방법을 찾고 있습니다. 이것이 내가 지금까지 가지고 있는 것입니다:
COUNTER=0;
inotifywait -m --format '%f' -e moved_from,moved_to ./ | while read FILE
do
if [ $COUNTER -eq 0 ]; then
FROM=$FILE;
COUNTER=1;
else
TO=$FILE;
COUNTER=0;
echo "sed -i 's/\/$FROM)/\/$TO)/g' /home/a/b/c/post/*.md"
sed -i 's/\/'$FROM')/\/'$TO')/g' /home/a/b/c/post/*.md
fi
done
작동하지만 감시 폴더 안팎으로 파일을 이동하지 않는다고 가정합니다. 또한 이벤트가 쌍으로, 먼저 Moving_from과 Moving_to로 온다고 가정합니다. 이것이 항상 올바른지는 모르겠습니다(지금까지는 작동합니다).
나는 inotify가 쿠키를 사용하여 이벤트를 연결한다는 것을 읽었습니다. 어떻게든 쿠키에 접근할 수 있나요? 쿠키가 부족하기 때문에 타임스탬프를 사용하여 이벤트를 서로 연결하는 것을 고려했습니다. 보다 안정적인 방법으로 FROM에서 TO까지 이동하는 방법에 대한 팁이 있나요?
답변1
나는 귀하의 접근 방식이 정확하다고 생각하며 쿠키 추적은 이를 수행하는 신뢰할 수 있는 방법입니다. 그러나 참조되는 inotify-tools(3.14) 소스 코드의 유일한 위치는 커널 API와 일치하는 헤더 cookie
정의입니다 .struct
가장자리에 사는 것을 좋아한다면 이 패치(이슈 #72)는 다음에 완전히 적용 가능합니다.3.14그리고 %c
이벤트 쿠키에 대한 16진수 형식 지정자를 추가합니다.
--- libinotifytools/src/inotifytools.c.orig 2014-10-23 18:05:24.000000000 +0100
+++ libinotifytools/src/inotifytools.c 2014-10-23 18:15:47.000000000 +0100
@@ -1881,6 +1881,12 @@
continue;
}
+ if ( ch1 == 'c' ) {
+ ind += snprintf( &out[ind], size-ind, "%x", event->cookie);
+ ++i;
+ continue;
+ }
+
if ( ch1 == 'e' ) {
eventstr = inotifytools_event_to_str( event->mask );
strncpy( &out[ind], eventstr, size - ind );
이 변경으로 인해 바이너리 libinotifytools.so
가 아닌 파일이 수정됩니다. inotifywait
설치 전 테스트:
LD_PRELOAD=./libinotifytools/src/.libs/libinotifytools.so.0.4.1 \
inotifywait --format="%c %e %f" -m -e move /tmp/test
Setting up watches.
Watches established.
40ff8 MOVED_FROM b
40ff8 MOVED_TO a
MOVED_FROM은 항상 MOVED_TO보다 먼저 발생한다고 가정합니다.fsnotify_move()
,이것은순서가 지정된 대기열, 비록 독립적으로 움직이지만가능한스크립트에서 MOVED_FROM 행(아마도 ID로 인덱싱된 연관 배열)을 볼 때 세부 정보를 캐시하고 일치하는 정보의 절반이 있는 MOVED_TO를 볼 때 처리를 실행합니다.
declare -A cache
inotifywait --format="%c %e %f" -m -e move /tmp/test |
while read id event file; do
if [ "$event" = "MOVED_FROM" ]; then
cache[$id]=$file
fi
if [ "$event" = "MOVED_TO" ]; then
if [ "${cache[$id]}" ]; then
echo "processing ..."
unset cache[$id]
else
echo "mismatch for $id"
fi
fi
done
(세 개의 스레드를 실행하여 한 쌍의 파일을 각각 10,000번씩 섞는 동안 순서가 잘못된 이벤트나 이벤트 인터리빙을 본 적이 없습니다. 물론 이는 파일 시스템 및 기타 조건에 따라 달라질 수 있습니다.)