Node.js에서 감시 대상 파일을 어디로 이동했는지 알 수 있습니까?

Question

fs.watch은 두 가지 가능한 이벤트 유형, 즉 'rename' 및 'change'만을 제공합니다. 파일 이름을 바꾸거나 (예 : mv 사용) 파일을 삭제 (예 : rm 사용)하면 fs.watch은 'rename' 이벤트를보고합니다.

파일을 이동 한 후에는 을 명시 적으로 닫지 않는 한 fs.watch에서 이벤트를 계속보고합니다. 그렇게되면 파일이 어디로 이동했는지 알고 싶습니다.

'change' 이벤트가 발생한 시점을 확인하기 위해 시스템의 모든 파일을 차례로 터치하는 방법이 있습니까?

Answer 1

노드가 파일 디스크립터에서 파일 이름을 가져 오는 인터페이스를 구현할 때까지는 (fd를 그대로 유지하고 거기에서 이름을 rename으로 가져올 때까지) 또는 FSWatcher를 따라 경로/파일 이름을 신뢰할 수있게 제공 할 때까지는 불가능합니다. 이벤트.

이 문제를 해결하려면 fs.link을 통해 대상 파일에 대한 임시 하드 링크를 만든 다음 변경 후에도 파일을 가져올 수 있지만 새 이름을 검색 할 수는 없습니다. http://eventmachine.rubyforge.org/EventMachine/FileWatch.html#M000291

Answer 2

난 당신이 파일의 원래 스탯을보고 파일의 식별자 인 inode를 참조 할 것 같아요

이 EventMachine 같은 문제를 가지고 흥미 롭군요. 파일이 하나의 파티션/파일 시스템/드라이브에서 다른 드라이브/파일 시스템/드라이브로 이동하지 않은 경우 (실제 복사 - 삭제 - 원래 작업이어야 함), inode은 동일합니다.

일반적으로 새 이름/위치를 얻으려면 inode의 조회 표가 없습니다. 시스템 전체를 체계적으로 검색해야 할 것입니다. 가능성이있는 장소를 먼저 볼 수 있다고 가정하면 나쁘지 않을 수 있습니다. 또는 제한된 지역 만 검색 할 수있는 경우.

임시 하드 링크 (Ricardo의 생각)를 사용하여 이동하지 않고 삭제되었는지 감지 할 수 있습니다. 링크 수는 하드 링크를 만들 때 1에서 2로 변경되며 임시 하드 링크에 대한 카운터가 삭제되면 2에서 1로 변경됩니다. 파일을 삭제하면 파일의 대상을 찾을 필요가 없습니다.

이 영역에 수천 개의 파일 만있는 경우 시스템에 따라 더 많은 해결책이있을 수 있지만 시스템에 따라 문제가있을 수 있지만 지연이있을 수 있습니다.

지연을 줄이려면 이미 알고있는 파일의 SQL 데이터베이스를 가질 수 있습니다 (inode). 예 : /folder/filea 및 /folder/fileb 두 가지 모두 다른 inode이 존재합니다. fileb이 filec으로 이동하면 statfilea은 이전에 이미 조회했기 때문에 inode을 찾을 필요가 없습니다. 이 로직을 사용하면 stat 명령의 수를 크게 줄일 수 있습니다. 그러나 filea이 삭제되고 fileb이 filea으로 옮겨지면이 극적인 축소 방법은 결과를 찾지 못합니다.이 경우 전체 작업 디렉토리를 검색해야합니다.

OS 폴더가 /etc 또는 /dev과 같은지 확인하는 옵션은 여전히 ​​있습니다. 최후의 수단으로 만 사용됩니다.임시 하드 링크를 사용하여 삭제를 탐지 할 수 있다고 가정하면 검색 할 필요가 없습니다.

작업 영역의 넓이는 어느 정도입니까? 파일이 특정 작업 폴더 내에서 항상 한 위치에서 다른 위치로 이동되는지 여부를 확실하게 알고 있습니까? 문제 환경에 대한 추가 정보가 도움이 될 것입니다.