動画277MBを「アップロードした」のに届いていなかった話

「きてたよ」ではなく、「まだ来てないっぽい」というメッセージと一緒に、スクリーンショットが送られてきた。開いていたのはGoogle DriveのiPhoneアプリで、画面には「このフォルダは空です」という一文だけがあった。

こちらでは、動画5本・合計277MBのコピーは確実に完了していた。ローカルの同期フォルダに、たしかにファイルは存在している。なのに、相手には届いていない。

「フォルダに置いた」は「アップロードした」ではなかった
疑うべきは「時間がかかっている」ではなく「動いているか」だった
副産物として、フォルダが2つできていた
対策は2つ。置く前のプロセス確認と、作成経路の一本化

「フォルダに置いた」は「アップロードした」ではなかった

前提を先に説明する。動画のレビューをスマホで完結させたくて、Google Drive for Desktopのローカル同期フォルダに、対象の動画ファイルをコピーする運用を組んでいた。理屈の上では、この同期フォルダに置いたファイルは、裏で自動的にクラウドへアップロードされるはずだった。

コピー自体は一瞬で終わった。lsで確認すると、ファイルサイズも正しい。ここで「作業は完了した」と判断してしまったのが、そもそもの見落としだった。

疑うべきは「時間がかかっている」ではなく「動いているか」だった

最初に疑ったのは、単純に時間の問題だった。277MBなら、アップロードに数分かかるのは自然だ。実際、少し待ってからDrive側のAPIで検索をかけても、ファイルはまだ見えなかった。「もう少し待てば出てくるはずだ」と、その場では思っていた。

だが、いくら待っても状況は変わらない。ここで初めて、「本当に同期プロセスは動いているのか」を確認することにした。

ps aux | grep -i "Google Drive" | grep -v grep

grep -v grepを挟んでいるのは、grepコマンド自身のプロセス名にも検索語が含まれてしまい、それを除外しないと「見つかった」と誤判定してしまうからだ。これを外すと、結果は何もヒットしなかった。同期を担うはずの常駐アプリそのものが、起動していなかった。

ローカルの同期フォルダは存在している。ファイルもそこに正しく置かれている。でも、そのファイルをクラウドへ運ぶはずの主体が、そもそも動いていなかった。フォルダに置くという操作と、アップロードされるという結果の間には、常駐プロセスという前提が挟まっていて、その前提を一度も確認していなかった。

open -a "Google Drive"でアプリを起動すると、状況は一変した。プロセス起動から数秒で、動画は次々とクラウド側に反映されていった。原因は容量でも回線速度でもなく、ただアプリが起動していなかっただけだった。

副産物として、フォルダが2つできていた

これで解決、とはならなかった。API側で確認すると、同じ名前の「review」フォルダが2つ存在していた。1つは空、もう1つに動画が入っている。

理由はすぐにわかった。同期アプリが停止している間に、別の経路（APIツール経由）で先に同じ名前のフォルダを作成していた。その後、アプリを起動してローカル側から同期をかけたところ、既存のクラウド側フォルダとはマージされず、新しいフォルダとして扱われてしまった。相手が見ていた「空のフォルダ」は、まさにこの最初に作った方だった。

前提の確認を1つ怠ったことが、原因の異なる2つの不具合を同時に生んでいた。