macOS で Dropbox がずっと「Syncing…」のまま完了しない。アプリ再起動しても、Mac 再起動しても、Finder 再起動しても直らない。数ヶ月この状態だった。
で、結局 FileProvider の内部データベースを直接調べたら原因が分かって、ファイル1つ消したら直った。という話。
結論
macOS の FileProvider フレームワークが管理している SQLite データベース（reconciliation_table）に、is_pending = 1 のまま永遠に処理されないアイテムが1件残っていた。ジョブキューは空なのに pending フラグだけ立ってる状態。これがデッドロックになって sync 完了に遷移できなくなっていた。
該当ファイル（Dropbox が自動生成したコンフリクトコピー）を Finder から削除したら、即座に「Up to date」になった。
症状
- Dropbox の UI が「Syncing…」のまま進まない
- ファイルの同期自体は動いている（新しいファイルは反映される）
- アプリ再起動、Mac 再起動、Finder 再起動、いずれも効果なし
- Dropbox のアンリンク → 再リンクでインデックス再構築しても、再構築後にまた「Syncing…」で止まる
調査手順
ターミナルから FileProvider の内部データベースを直接調べる。ここから先はターミナル操作が必要。
1. FileProvider データベースの場所を確認
ls ~/Library/Application\ Support/FileProvider/Dropbox/database/db というファイルがある。これが FileProvider の同期状態を管理している SQLite データベース。
2. pending アイテムを探す
sqlite3 ~/Library/Application\ Support/FileProvider/Dropbox/database/db \
"SELECT count(*) FROM reconciliation_table WHERE is_pending = 1;"ここで 0 以外の数字が出たら、それが「Syncing…」で止まっている原因。自分の場合は 1 だった。53万件中たった1件。
3. 犯人の詳細を見る
sqlite3 ~/Library/Application\ Support/FileProvider/Dropbox/database/db \
"SELECT fs_id, fp_id, fs_structural_filename, fp_scheduling_state, fs_scheduling_state
FROM reconciliation_table WHERE is_pending = 1;"自分の環境だとこう出た:
-11692|dbitem:530699|somethumbnail (XXX の競合コピー 2026-03-14).png|0|4fp_scheduling_state = 0（FileProvider 側で未処理）なのに fs_scheduling_state = 4（ファイルシステム側では完了）。この不整合がデッドロックの正体。ジョブも生成されないから永遠に解消されない。
4. ファイルのパスを特定する
pending アイテムの親フォルダを再帰的に辿ってフルパスを組み立てる:
sqlite3 ~/Library/Application\ Support/FileProvider/Dropbox/database/db "
WITH RECURSIVE path_trace(id, parent, name, depth) AS (
SELECT fs_id, fs_structural_parent_id, fs_structural_filename, 0
FROM reconciliation_table WHERE is_pending = 1
UNION ALL
SELECT r.fs_id, r.fs_structural_parent_id, r.fs_structural_filename, pt.depth + 1
FROM reconciliation_table r
JOIN path_trace pt ON r.fs_id = pt.parent
WHERE pt.depth < 10
)
SELECT name FROM path_trace ORDER BY depth DESC;
"これでルートからのパスが出る。depth の深い方がルートに近い。
5. ファイルを削除
特定したファイルを Finder から削除する。自分の場合はコンフリクトコピー（XXX の競合コピー というファイル名のやつ）だったので、元ファイルは別に存在していて削除して問題なかった。
6. 確認
sqlite3 ~/Library/Application\ Support/FileProvider/Dropbox/database/db \
"SELECT count(*) FROM reconciliation_table WHERE is_pending = 1;"0 になっていれば OK。Dropbox の UI も「Up to date」に変わっているはず。
補足: ジョブキューの確認
pending アイテムとは別に、ジョブキューが詰まっている場合もある:
# ジョブキューの状態
sqlite3 ~/Library/Application\ Support/FileProvider/Dropbox/database/db \
"SELECT scheduling_state, count(*) FROM jobs GROUP BY scheduling_state;"
# pending-set フラグ
cat ~/Library/Application\ Support/FileProvider/Dropbox/non-empty-pending-setジョブキューが空なのに non-empty-pending-set が true なら、上記の reconciliation_table に原因がある。
補足: プロセスの状態確認
FileProvider 周りのプロセスが動いているかどうかも確認できる:
# DropboxFileProvider の CPU/メモリ
ps aux | grep DropboxFileProvider | grep -v grep | \
awk '{print "PID:", $2, "CPU:", $3"%", "MEM:", int($6/1024)"MB"}'
# macOS の fileproviderd（システムプロセス）
ps aux | grep fileproviderd | grep -v grep | \
awk '{print "PID:", $2, "CPU:", $3"%", "MEM:", int($6/1024)"MB"}'CPU が 0% で pending アイテムが残っているなら、完全にデッドロックしている。
なぜこうなるのか
推測だけど、Dropbox のインデックス再構築中にコンフリクトコピーが生成されると、FileProvider の列挙処理とコンフリクト生成が競合して、reconciliation_table の FP 側エントリが正しく登録されないっぽい。レースコンディション。
他のコンフリクトコピーは fp_scheduling_state = 4（正常に処理済み）なのに、再構築中に生成されたこの1件だけ fp_scheduling_state = 0 のまま取り残された。Dropbox のバグと言っていいと思う。
まとめ
- 「Syncing…」で止まる原因は FileProvider の
reconciliation_tableにis_pending = 1のアイテムが残っていること（少なくとも自分のケースでは） - sqlite3 で直接データベースを調べれば犯人が特定できる
- 該当ファイルを削除すれば即座に解消される
- 再起動は意味ない。問題はプロセスじゃなくてデータの状態不整合
同じ症状で困ってる人が sqlite3 をターミナルで叩ける人かどうかは分からんけど、少なくとも Dropbox のサポートに「reconciliation_table の is_pending を確認してくれ」と言える材料にはなるかなと。
you