私はinotifyを使用してディレクトリの変更を監視し、rcloneを使用してバックアップスクリプトを起動し始めました。だから私はDebianでRecollを使用していることを活用して、inotifyが機能しなくてもRecollが検出した変更でrcloneを起動できると思いました。
インデックスが更新されるたびに、最後に変更または生成されたファイルを知らせる明確なログファイルがRecollに見つかりません。頑張ってきた回想_状態スクリプトを使用するか、xapian-delveを使用してxapiandbを読み取ろうとしましたが、成功しませんでした。
Recollインデックスで最後に追加または更新されたドキュメントのリストを取得する方法をご存知ですか？
ベストアンサー1
ファイル変更の確認を使用することはrecollindex興味深いアイデアですが、ユースケースを理解している場合は必要ありません。 Rcloneはすでにファイルサイズと修正時間を調べて、何を更新するかを決定します。
通常、rclone はファイルの変更時間とサイズを確認して同じであることを確認します。このフラグがセットされると、rclone はファイルのハッシュとサイズをチェックし、ファイルが同じであることを確認します。
これは本質的に同じですrecollindex。
ファイルが変更されたかどうかをテストするには、ctimeの代わりにmtimeを使用してください。常に使用されるサイズに加えて、時間も使用されます。
詳しくはこちらのソースコードをご覧ください。
// File signature and up to date check. The sig is based on
// m/ctime and size and the possibly new value is checked against
// the stored one.
したがって、rclone本質的に同じ比較を実行してインデックスを更新するのではなく、リモートバックアップのみを更新しますrecollindex。現在実行しているのと同じ方法で実行rcloneできます。rclonerecollindex
さらに、recollのインデックスを使用してバックアップする必要がある項目を決定するには、次のような多くの欠点があります。
skippedNamesRecollindexはの項目に応じて、~/.recoll/recoll.conf多くのファイル（PNGやJPEGファイルなど）のインデックス作成をスキップします。おそらくこれらのファイルをバックアップしたいと思います。このインデックスはファイルシステムの現在の状態を反映しません。実際、ファイルシステムは
recollindex実行時に変更される可能性があります。したがって、インデックスは、更新する必要がある項目を決定する信頼できる方法としては使用できません。
ただし、リアルタイムモニタリングモードで起動すると、recollは使用中の変更を検出するために特別なことを行いません。InotifyまたはFAM/GAMIN 舞台裏から。気になる場合は、ソースコードの関連部分へのリンクは次のとおりです。
スクリプトrecoll_status.pyはポーリングのみを実行します~/.recoll/idxstatus.txt。これには、変更されたファイルの完全なリストも含まれません。現在インデックス化されているファイルのみが表示され、すべてのファイルではなく時々更新されます。
// Update the status file. Avoid doing it too often. Always do
// it at the end (status DONE)