ZimaOS 1.6.2では、Filesに少なくとも2種類の大きく異なる症状が発生しており、1つのバグとして診断すべきではありません。 1つは、内容は移動されるものの空の元フォルダーが残る、再現性のある移動処理のリグレッションでした。もう1つはクラウドドライブのマウントおよび認証エラーで、確認されたケースの1つでは、ブラウザーをハードリフレッシュすると解消しました。
フォルダー移動のリグレッションには、現在のバージョンに関する重要な境界があります。ZimaOS 1.7.1では、切り取り後に空のフォルダーが残る問題が明示的に修正されています。現在の安定版を使用していても同じ症状が発生する場合は、古い1.6.2向けの回避策を適用する前に、正確なバージョンを確認してください。
問題1：移動後に空の元フォルダーが残る
報告されたパターンは非常に具体的でした。内部のext4 SATAドライブ間でファイルとサブフォルダーは正常に移動されるものの、元の最上位フォルダーだけが空の状態で残りました。コピー操作ではこの問題は発生せず、動作は1.6.2へのアップデート後に始まりました。
同じバグかどうかを確認する方法
- 1つのサブフォルダーと数個のファイルを含む小さなテストフォルダーを作成します。
- ZimaOSのFilesアプリを使用して、2つのローカルストレージ間でそのフォルダーを移動します。
- すべての内容が移動先に到着したことを確認します。
- 元の場所に空の親フォルダーだけが残っているか確認します。
ファイルが見つからない、権限が変更される、または移動先がローカルのext4ストレージではなくネットワーク共有である場合は、別の経路の問題であり、この過去のリグレッションが原因だと決めつけないでください。
フォルダー移動のリグレッションはZimaOS 1.7.1で修正済み
ZimaOS 1.7.1のリリースノートには、特定の状況でフォルダーを切り取った後に空のフォルダーが残る問題の修正が明記されています。
つまり、まだ1.6.2を使用しているシステムに対する最善の解決策は、バックアップを作成したうえで現行の安定版にアップデートすることです。残ったフォルダーを自動的に削除するスクリプトを作成することではありません。
問題2：クラウドドライブに「ストレージがマウントされていない」またはインスタンスエラーが表示される
クラウドドライブのエラーは、クラウドプロバイダーの認証、ZimaOSに保存されたトークン、バックエンドのマウント、ブラウザーのUI状態など、複数の層で発生する可能性があります。上のスクリーンショットは深刻に見えますが、告知スレッドのあるユーザーは、IceWhaleの案内に従ってハードリフレッシュを実行したところ復旧しました。
ステップ1：ZimaOSのページをハードリフレッシュする
通常の再読み込みでは、古いJavaScriptやキャッシュされたセッションデータが再利用されることがあります。ブラウザーのハードリフレッシュ方法を使ってからFilesを再度開き、クラウドアカウントが引き続き一覧に表示されるか確認してください。
ステップ2：プロバイダーが現在サポートされているか確認する
現在のZimaOSクラウドドライブガイドでは、Google Drive、Dropbox、OneDriveとのFilesへの直接統合について説明しています。現在のインターフェースには、サポート対象のプロバイダーが表示されます。
ステップ3：セッションが実際に壊れている場合のみ再認証する
ハードリフレッシュ後もドライブを利用できない場合は、そのマウントに依存するローカルタスクを把握していることを確認してから、アカウントを削除して再接続してください。表示だけの問題に対して、最初から再認証を行うべきではありません。
UIのキャッシュ問題と実際のマウント問題を見分ける方法
UIの問題は、ハードリフレッシュ、別のブラウザー、新しいプライベートセッションなどによって状況が変わることがあります。バックエンドのマウント問題はブラウザーを変えても解消せず、クラウドマウントを使用するバックアップタスクやアプリケーションのパスにも影響する可能性があります。
認証情報を削除する前に、この違いを確認してください。1つのブラウザーではFilesが壊れているように見えても別のブラウザーで動作する場合は、フロントエンドのセッションに注目します。すべてのクライアントとサービスで同じストレージが見つからない場合は、マウントまたは認証の層を調査してください。
ローカルファイル移動のバグとクラウド認証エラーを混同しない
1.6.2の告知には、互いに関係のないアップグレード報告が多数寄せられました。そのスレッドを「ストレージのバグ」に関する曖昧な記事にしてしまうと、トラブルシューティングが難しくなります。ローカルext4の切り取り動作とOAuth／クラウドマウントのエラーでは、根拠となる情報、障害が発生する箇所、解決策がそれぞれ異なります。
クラウド統合の概要では、クラウドとローカルのより広範なワークフローを確認できます。
現在のZimaOSでも問題が続く場合の対処方法
フォルダーの問題については、現在のZimaOSのバージョン、移動元と移動先のファイルシステム、両方がローカルかどうか、操作が切り取り／移動だったのかコピーだったのかを記録してください。クラウドの問題については、プロバイダー、ブラウザー、正確なエラー内容、ハードリフレッシュで変化するかどうか、別のクライアントからドライブを利用できるかどうかを記録してください。
これにより、古い1.6.2の不具合が再発したと決めつけるのではなく、新しいバグ報告を有用なものにできます。
よくある質問
ZimaOS 1.7.1では、ファイル移動後に残る空のフォルダーが修正されていますか？
はい。1.7.1のリリースノートには、特定の状況でフォルダーを切り取った後に残る可能性がある空のフォルダーを修正したと明記されています。
1.6.2で空のフォルダーを手動で削除してもよいですか？
移動に失敗したファイルがないことを確認したうえで、残った空のフォルダーを削除することはできます。ただし、長期的にはアップグレードする方が適切です。すべてのファイルが正常に移動されたことを確認するまで、削除を自動化しないでください。
なぜハードリフレッシュでクラウドドライブのエラーが解消することがあるのですか？
アップグレード後、ブラウザーに古いフロントエンドの状態やセッションデータが残ることがあります。バックエンドのマウントが正常であれば、フロントエンドのアセットとセッションを更新することで、アカウントを変更せずにUIを復旧できる場合があります。
OneDriveやGoogle Driveをすぐに切断して再接続すべきですか？
いいえ。まずハードリフレッシュと、別のクリーンなブラウザーセッションを試してください。マウントまたはトークンが実際に無効な場合にのみ、再認証を行ってください。
