クラウドストレージサービス、例えば Box、Dropbox、Google Drive、Microsoft OneDrive といったものたちが、Apple の File Provider 拡張への切り替えを済ませたり、あるいは切り替えの最中であったりしている。この新しいアプローチは従来のものよりも筋の通ったものではあるけれども、ユーザーにとっては使い方に変化が起こることを意味していて、大量のデータを持っている人、あるいは複雑なワークフローを組み立てて使っている人にとって問題が起こることもある。Adam Engst が、皆さんが知っているべきことを深く掘り下げる。Adam はまた、TidBITS の電子メール号を印刷したり PDF に書き出したりした際に号に含まれる画像が欠落してしまうという奇妙な問題に取り組む。それからイエローの iPhone 14、Apple Music Classical、そして Microsoft Outlook の無料化についてニュースをお届けする。今週注目すべき Mac アプリのリリースは Fantastical 3.7.8、Audio Hijack 4.1.2、Yojimbo 4.6.3、1Password 8.10.1、SpamSieve 2.9.52、ChronoSync 10.3.4 と ChronoAgent 2.2.3、FastScripts 3.2.5、それに GarageBand 10.4.8 だ。
TidBITS の週刊号を紙に印刷したいと思う人はあまり多くないだろうから、サポートを担当してくれている Lauri Reinhardt がある読者からの問い合わせを私に転送してきて、そこに TidBITS の電子メール号をすべての画像付きで印刷するにはどうすればよいかと書いてあったので私はちょっと驚いた。Lauri も私もそんなことを試みたことは一度もなかったのだが、やってみるとその読者の言うことが正しいと分かった。TidBITS の週刊号を紙に印刷したり、あるいは PDF に書き出したりすると、画像があるべきところが何もない余白になってしまう。
TidBITS#1648 を PDF に書き出して Preview で表示したら、画像がロードされない Mail の Protect Mail Activity 設定をいじっても何も変わらなかったし、画像はメッセージ自体の中にはちゃんと表示された。遠隔のコンテンツをロードするかどうかという点には何の関係もなかった。さらにもっと困惑させられたのは、私が Gmail 用に使っているアプリ Mimestream でも同じ問題が生じたのだが、それは macOS 12 Monterey の下でのみのことであって、macOS 13 Ventura では問題が起こらなかった。また、Gmail のウェブインターフェイスからの印刷でも、何の問題も起こらなかった。
私たちの週刊号の生のソースを読んでみると、すぐに重要な証拠が判明した。記事の中のすべての IMG タグに付けられた loading="lazy" アトリビュートだ。号の冒頭近くにあるスポンサーのバナーにはそのアトリビュートが付いていないので、PDF に画像がちゃんと表示されている。奇妙だ。そこで私は Mimestream の開発者 Neil Jhaveri に尋ねてみた。彼は以前 Apple で Mail の開発を担当していたからだ。彼によれば、Mail はスクリーン外にウェブ表示を生成して、その書類の "load" 部分が到着するまで待ち、それを受けて "print" する。ところがloading="lazy" という命令によって画像がスクロールして見える範囲に来るまではロードされないようになり、印刷をする際にはそのスクロールが起こらないので画像がロードされないままになるというのだ。Mimestream にも、少なくとも Monterey においては同じ問題が起こる。なぜなら、Mail と同様に印刷の際に WebKit を利用するからだ。Neil は loading="lazy" アトリビュートを外すのがいいと勧めてくれた。彼の意見では、画像は (少なくとも縦横の長さのアトリビュートが設定されていれば) いずれにしてもロードされるより前にページのレンダリングを妨げたりしないのだからとのことだ。
私がこの会話をしている間に、Lauri がたまたま回避策に遭遇し、考えてみればそれは Neil の説明とも合致していた。彼女はきっと画像が大き過ぎてロードに妨げが生じたのだろうと推測して、Print ダイアログの Scaling オプションを使って縮小することを試みた。すると、少なくともいくつかの画像は表示されるようになった。私もテストしてみて、スケール率を 99% に変更すれば一部の画像が表示されるようになることを確認した。ただ、表示されてもぼやけて見えるし、やはり全然表示されない画像もある。けれどもスケール率をもっと下げて例えば 87% にしておき、それから書類のプレビューを上から下まで全部スクロールして見て、その後で書き出すと、その結果の PDF にはすべての画像が鮮明に表示されていた。あとでスケール率を 100% に戻してもそのことは変わらなかった。推察するに、Print ダイアログで出力をスケールすると WebKit が強制的にすべての画像をロードするようになり、結果として画像が見えるようになるらしい。
TidBITS の開発担当者 Eli Van Zoeren に IMG タグから loading="lazy" アトリビュートを削除するように頼んだところ、彼は WordPress が自動的にそれを挿入しているのだと説明した上で、TidBITS の電子メール版からそのアトリビュートを取り除くフィルターを追加してくれた。(彼のコードはスポンサーのバナーを別のやり方で号に追加しているので、バナーにはもともとそのアトリビュートが付かなかった。) その次の号を私はワクワクしながら待ったが、問題がまだ解消されていないことに気付いてがっかりした。結局判明したのは、Eli がフィルターをかけて loading="lazy" を取り除いた後に、WordPress がその代わりにそれによく似た decoding="async". というアトリビュートを挿入していたことだった。そこでもう一度モグラ叩きのようにそのアトリビュートも削除すると、ようやく問題が完全に消えた。
TidBITS#1649 を PDF に書き出して Preview で表示したら、画像が正しくロードされた そういう訳で、そもそも TidBITS の週刊号を紙に印刷することはお勧めしないけれども (TidBITS の号は印刷用にフォーマットされておらず、しかも印刷すれば相当量の紙を消費する)、今はちゃんと画像が見えるようになっているはずだ。興味深いことに、上に示したスクリーンショットは両方とも、最後のところで空白のページを示している。いったいなぜ Mail が空白ページを最後に付けるのか私は知らないが、とにかく無駄なページは削除しておくことをお勧めしたい。File > Export to PDF を選び、その PDF ファイルを Preview で開いて、空白のページ (およびその他の不必要なページ) をサイドバー上で選んで、それらを削除してから、その後で印刷しよう。
この問題の影響を受けている人たちはあまり多くいないと信じたいが、少なくとも一人の TidBITS 読者のためにお役に立てたならば嬉しい。そして、これと同様の問題に遭遇した他の人たちにも、この記事が参考になって問題をより早く解決できる力になれるならと願いたい。
討論に参加
昨年を通して、Box 、Dropbox 、Google Drive 、Microsoft OneDrive (おそらく他にもあるだろう) などのクラウドストレージサービス各社は従来それぞれがカスタマイズしたカーネル拡張を使っていたのをやめて、Apple の比較的新しい File Provider 拡張を使うやり方へと移行した。この拡張は Apple が認可したフレームワークを提供し、遠隔にあるファイルを macOS の中へ統合させるとともに Finder の中でそのファイルを表示する。私は一年前の記事“クラウドストレージの見通しは不透明、嵐の可能性もあり ”(2022 年 2 月 4 日) の中でこの話題に触れた。
この File Provider 拡張 が最初に登場したのは macOS 12.1 Monterey においてであったが、Apple の Developer サイトにはこれが macOS 10.15 Catalina で利用できるようになっていたかもしれないと示唆する記述が見られる。古いバージョンの macOS はこの拡張に対応していないので、古いシステムを使っている人にとっては今のところ何も変わらないはずだ。いずれはどこかの時点でクラウドストレージサービス各社が古いシステムに対応しなくなる可能性が高いが、それがいつになるかは予想がつかない。(以下に述べることはすべて私が macOS 13.2.1 Ventura でテストした結果による。Monterey では細かな点が違っていることもあり得るし、むしろその可能性は高いだろう。)
クラウドストレージサービス各社にとっては、File Provider 拡張を採用する以外の選択肢はないと思えたのだろう。なぜなら、Apple が将来どこかの時点でカーネル拡張を廃止する予定だと述べたからだ。現時点でそれはまだ起こっていないけれども、Apple は多くの場合開発者たちが新しいプログラムに馴染めるように数年間の猶予を与えている。
私が理解しているところでは、Box、Google、Microsoft の各社は既にそれぞれの Mac ユーザーを File Provider のやり方へ移行させる仕事を終えているけれども、(おそらく日常的な Mac ユーザーの間で最も人気を得ている) Dropbox は最近になってやっとベータプログラムの外にいる一般ユーザーに向けても新しいやり方への移行を働き掛け始めたばかりのようだ。(まだベータへの参加を呼び掛けられているだけのユーザーたちもいる。) 一般的にクラウドストレージのプロバイダはゆっくりと時間を掛けて変更を展開するものだし、まず一部の顧客のみに展開することで反応を調べたり懸念の声を聞き分けたりサポートの負担を分散させたりできるようにすることも多いので、実際の展開がどの程度終わっているのかを見極めるのは難しい。自分の Mac のうち一台は File Provider のやり方にアップグレードされているけれども他の Mac はまだカーネル拡張を使っていると報告した Dropbox ユーザーさえいる。
クラウドストレージが首尾一貫したやり方で macOS に統合されるのは良いことだが、Apple の File Provider 拡張へ切り替えようとする際には二つの重要な変更点がもたらされ、それに合わせてあなたが作業する方法を変更する必要が生じる。
第一の変更点は、ローカルなファイルが保存される場所についてだ。今後は、すべてのクラウドストレージサービスがファイルを ~/Library/CloudStorage に保存しなければならない。(つまり、あなたのホームフォルダの中にある Library フォルダの中の CloudStorage フォルダだが、たいていのユーザーにとってアクセスするのは単純ではない。Library フォルダはデフォルトで隠されているからだ。) 一貫性を実現するためにも、標準的な場所が決まるというのは良いことだ。なぜなら、個々のサービスがそれぞれのファイルをどこに置いているかをユーザーが覚えている必要がないからだ。しかしながら、まさに Mac OS X がホームフォルダを導入してその中に今では標準的なものとなったサブフォルダ (Desktop、Documents、Library、Movies、Music その他) を置いた時に起こったように、柔軟性が失われる結果として一部のユーザーは痛みを感じることになるだろう。
第二の変更点は、ファイルがローカルとオンラインの両方に存在するか (通常 "offline" または "pinned" と呼ばれる)、それともオンライン上のみに存在するか ("online-only" と呼ばれる) の違いだ。それぞれが長所と短所の両方を持つ：
Offline ファイル はクラウド上に置かれると同時にローカルドライブ上にも置かれていて、素早くアクセスできる。その反面、ローカルなストレージ容量を消費するので、空き容量が少なければ問題が起こるかもしれない。ファイルがこの状態にあることを示すような目で見て分かる印はない。Online-only ファイル は、ローカルにはただプレースホルダーとなるアイコンとしてのみ存在しており、それが開かれた時点で初めてファイルが取り込まれる。Finder では、ファイルの名前の脇に小さなクラウドアイコンが示される。このやり方は容量を節約することができるが、大きなファイルや、遅い接続の場合にはロードするための時間が掛かる。もちろん、接続がなくなれば online-only のファイルは一切利用できなくなる。
クラウドストレージサービスを File Provider のやり方へ移行させた後は、原則としてすべてのファイルとフォルダが online-only だと思っておくべきだ。ただし例外もある (それはその小さなクラウドアイコンがないことで見て取れる) のだが、後で述べるようにそれらのファイルは Quick Look で中身を見たり、Spotlight で索引付けをしたり、Time Machine やその他のバックアップアプリを使ってバックアップしたりといったことができない。
どんなファイルやフォルダも、その状態をあなたがコントロールできる。ファイル名やフォルダ名の隣にあるクラウドアイコンをクリックすればダウンロードが始まり、状態が online-only から offline に変わる。ファイルを Control-クリックすれば、ダウンロードしたり (その結果 offline になる) あるいはダウンロードしたものを削除したりする (その結果 online-only になる) コマンドが示される。Dropbox は (下左図のように) このポップアップメニューの下の方にある Quick Actions セクションに出る Make Available Offline または Make Online-Only コマンドに依存して働く。Google Drive は (下右図のように) メニューの一番上近くに Download Now または Remove Download コマンドを置き、それに加えて Quick Actions もある。
当然ながら、online-only のファイルをアプリで開けば、自動的にダウンロードされる。サードパーティのアプリの中には開こうとしたファイルがまだダウンロードされていない場合に不具合を起こすものもあり得るので、もしもエラーが出れば、そのファイルが offline で利用できるのを確認してからもう一度やってみよう。
誤解のないように言っておくと、ファイルが offline か online-only かの違いは別に新しいことではなく、File Provider 拡張のみに言えることでもない。あらゆるクラウドストレージサービスは以前から、ファイルやフォルダのうちどれがローカルにも置かれていて、どれがオンライン上のみに存在しているかを明確に述べる手段を提供してきた。細かな事柄やその意味合いはいくらか異なっていたかもしれないが、概念そのものはずっと同じであった。
では、File Provider によるそれらの変更点が引き起こす影響のいくつかについて以下で見て行こう。以下では私がいつも使っているサービスである Dropbox と Google Drive について述べるが、Box や OneDrive についてもたいていの場合同様のことが言えるはずだ。
サイドバー上の位置が変わるかもしれない
File Provider のやり方は、いろいろなクラウドストレージサービスに互いの同等性をもたらすとともに、macOS における他のストレージの形との同等性ももたらす。その結果として、Apple はそれらが Finder ウィンドウのサイドバー上で Locations セクションの中に表示されることをデフォルトとすると定めた。Finder > Settings や Preferences > Sidebar を使ってサイドバー上の表示を丸ごとオン/オフすることもできる。
場所が変わったことでちょっとした混乱が起きるかもしれない。もしもこれまでサイドバー上で Locations セクションを閉じたままにしていたり、あるいは例えば Dropbox や Google Drive をセクションに置いて頻繁にアクセスしていたりしたならば、突然見えなくなって戸惑うかもしれない。けれども、サイドバー上でクラウドストレージサービスの項目を Locations から Favorites へドラッグして動かしたり、あるいは Locations と Favorites の両方に置いておくことさえ可能だ。
これはごくマイナーな変更であって、好きなように調整し直すのも簡単だ。ただ、この点を最初に述べたのは、あなたがまずサイドバー上のすべての項目を一度クリックしてみて、それが動作すること、さらに重要なのはそれが正しく動作することを確かめておくのが大切だと思うからだ。
ローカルなフォルダで接続が切れることがあるので注意が必要
サイドバー項目が正しい場所に行かなくなる可能性があるのはなぜか？ それは、クラウドストレージサービスが従来のカスタムカーネル拡張から File Provider 拡張へ切り替える際に、そのローカルフォルダがそれまであった場所から ~/Library/CloudStorage へ移動させられるからだ。いや、少なくともそれが目標なのだ。
(ここでちょっと注意しておくと、Finder でホームフォルダの中に Library フォルダが見当たらない場合は、Option を押しながら Go (移動) メニューをクリックすると、メニューの中で Library 項目が見えるようになる。あるいは、ホームフォルダが開いている状態で View > Show View Options を選び、そこで Show Library Folder を選んでおけば常に見えているようになる。)
ユーザーの中には (私たちも含めて) ローカルなフォルダが動いておらず、しかもサービスとの接続が切れてしまっているという経験をした人たちもいる。クラウドストレージサービスは直ちに新しい場所との間で同期を始めるので、結果として異なる 2 つの (例えば) Dropbox フォルダが生まれてしまうことになる。片方は ~/Dropbox で、もう片方は ~/Library/CloudStorage/Dropbox という具合だ。
クラウドストレージサービスは古い場所にエイリアスのように見えるもの (実際には symlink) を作成してユーザーのために継続性を提供しようとし、結果的に事態をなおさら混乱させてしまう。あなたのホームフォルダにあるその Dropbox フォルダは、果たして symlink なのか、それとも接続の切れたローカルフォルダなのか？ それを確かめるには、Terminal を開いて ls -l とタイプする。(もしも既にホームフォルダにいるのでない場合には、まず始めにcd コマンドを使っておく。) 下の図でお分かりのように、私のホームフォルダの中には Dropbox と Google Drive のフォルダの symlink がある。一番左のカラムの冒頭にある l の文字が、それが symlink であることを示している。それに比べて Downloads や Library などディレクトリは冒頭が d で始まり、私が比較のために作成したエイリアス Dropbox Demo Alias は冒頭が - で始まっている。
Dropbox (TidBITS Publishing) という symlink が何なのか私には分からない。何年も前に TidBITS 用に Dropbox Business アカウントを作って少しだけ試してみたことに関係があるかもしれない。 分かったことを確認するには、新しいファイルをローカルフォルダの中へコピーして、それからクラウドストレージサービスのウェブサイトでそのファイルがアップロードされたかどうかチェックすればよい。
実際に接続が切れたローカルフォルダが見付かった場合には、そのフォルダの内容を抜き取り検査して、それぞれのオンライン版が存在するかどうか確かめる。私のやり方は Finder で List View を使い、Date Modified の順に並べて、それからフォルダを一つ一つ展開して最新のファイルが両方にあることを確かめるというものだ。私の場合は Google Drive でこの状況に遭遇したが、同期されていなかったファイルはほんの数個だった。けれどももし数多くの違いがあれば、ChronoSync などの同期ソフトウェアを使ってどのファイルを移動すべきか見極めるとよいだろう。
ファイルが全部同期できたなら、接続の切れたフォルダを忘れずに削除しておこう。そのままにすると、後日うっかり使ってしまうかもしれないからだ。もしもその後サービスが自動的に symlink を作成してくれなければ、以下の手順で作成しておくことをお勧めする：
ITerminal で、ます cd とタイプしてから Return を押し、ホームフォルダが開いているようにする。
ln -s とタイプする。(必ず s の後に空白文字をタイプしておく。)Finder で Go > Go to Folder を選び、~/Library/CloudStorage とタイプしてから Return を押す。これでそのフォルダが Finder で開く。
そこに見えるクラウドストレージサービス (例えば Dropbox や Google Drive) のフォルダを、Finder から Terminal ウィンドウの中へドラッグする。すると、ln -s の後にそのパス名が挿入される。このやり方が必要なのは、少なくとも Google Drive については実際に付いている名前が見えているものとは違うからだ。最後に Return を押せば symlink が作成される。
ローカルなファイルやフォルダへの参照が壊れることがある
理想の世界ならば、クラウドストレージサービスが ~/Library/CloudStorage の中に新たに置かれたそのローカルフォルダのエイリアスを従来それがあった場所に作成することで、そのフォルダの中にあるすべてのエイリアスやその他の参照なども従来通りに働き続けるはずだ。
しかしながら、実際には必ずしもそうはならない。とりわけ、接続の切れたローカルフォルダをクリーンアップしなければならなくなったような場合にはそれが言える。さきほどお勧めしたように接続の切れたローカルフォルダを削除した場合には、その内容のファイルやフォルダを指していたエイリアスはすべて壊れる。それは良いことだ。なぜなら、そのことでエイリアスを作成し直さなければならないと分かるからだ。
同じように、BBEdit、Keyboard Maestro、Transmit といったアプリは Mac と Mac の間で設定やその他のデータを同期する目的でサポートファイルをクラウドストレージに保存するオプションを提供している。上記の理想の世界においては、すべてがこれまで通りに動作するはずだろう。実際、私の体験を言えば最近の Dropbox の移行に際して私が Dropbox に保存していた数個の Keyboard Maestro マクロ (Automator ワークフローを参照するもの) も BBEdit テキストフィルターも、すべて問題なく動作を続けた。
けれども、そのようなファイルへの参照がすべて新しい場所でも働き続けるという保証は何もないし、そもそも同期の設定のためにクラウドストレージを利用するようなアプリの場合には問題が起こってもすぐに気付けるとは限らない。どんなアプリが同期のためにクラウドストレージを利用しているかのヒントを探したければ、あなたのクラウドストレージフォルダ、とりわけ Dropbox のフォルダの内容に隅から隅まで目を通すとよい。
外部ドライブサポート消滅、OneDrive は例外
新しい File Provider 方式の最も大きな制約は ~/Library/CloudStorage が内部ドライブ上に置かれることである。クラウドストレージサービスに何テラバイトものファイルを持つ人には、これは大問題である。
以前は、クラウドストレージサービスのローカルフォルダを住まわせたいと思う場所を指定する事が出来たので、大きな外部ドライブ上にそれを置くのは簡単であった。File Provider 方式だと、それはもはや可能ではない。少なくとも、Box , Dropbox , そして Google は今の所そう言っているが、Microsoft は OneDrive に関して回避策を取った 。それは "sync root" (これは ~/Library/CloudStorage の中に留まらなければならない) をキャッシュから分離することで成されている。キャッシュは外部ドライブ上にあっても問題ない。
ユーザーはこの変更に憤慨しているが、オーディオやビデオの処理ワークステーションを Dropbox を使って巨大な共有ファイルでアップデートされる様にしている人達は取り分けそうである。
ニュースは必ずしも悪いものばかりではない。17 February 2023 に、Dropbox は外部ドライブサポートの喪失についての長文で辛辣なスレッドの中に一つの知らせを載せて、同社は解決に向けて努力しており 、Dropbox フォルダを外部ドライブ上に置いている人は当面の間アップグレードされないと言っている。
Dropbox の対応など待っていられないと言うのであれば、オープンソースの Dropbox クライアント Maestral を考えてはどうであろうか。それは Dropbox フォルダを好きな所に置かせてくれ、それには外部ドライブも含まれる。Maestral は公開の Dropbox API に依存しており、それはファイルの保存から保存迄の変更分だけが - バイナリ diff - 転送されないようにしている。代わりに、Maestral はファイル全体を転送しなければならず、より時間がかかりそしてより多くの帯域を使用する。Maestral は Dropbox の基本アカウントの機器３台までの制約には該当しない ("Dropbox、無料のアカウントを３台までに制限 " 14 March 2019 参照)。
他の回避策もあるかも知れない。それは自分のホームフォルダ全体を外部ドライブに移すこと である。System Settings/Preferences > Users & Groups にあるユーザーを Control-クリックし、Home Directory フィールドにアクセスする。技術的に習熟しており、複数のバックアップを始めから作成済みでない限り、これをやろうなどと思わないように - テストアカウントを使う場合であっても。
ホームフォルダを外部ドライブに移すことが希望通り働いたとしても、負の側面もある。まず、ラップトップではうまく行かないであろうし、高価な SSD に大枚をはたいても良いと思わないのであれば、ハードドライブのより遅い性能に泣かされることになるであろう。加えて、外部ドライブ上にあるアカウントにログインしている最中に macOS アップデートをインストールすることがどの様に問題を生ずる可能性を持つかについてもオンラインで討議されている ；勧められているのは、内部ドライブ上の管理者アカウントを使って macOS をアップデートすること のようである。もしこのやり方を試すのであれば、その結果をコメントで知らせて欲しい。
必要となる技術的な裏付けと優良なバックアップを持っている冒険好きの人に対しては、試してみることの出来る選択肢が他にもある - 繰り返しなるが、それ等が働いたかどうかコメントで知らせて欲しい：
Dropbox: もし Dropbox を File Provider 方式に移行済みなのであれば、ユーザーの一人が別の Dropbox Community スレッド に回避策案を載せている。それは symlink を使って外部ドライブ上にある Dropbox フォルダに向けてやることに関わっており、Microsoft が OneDrive でやったことに似ている。最近のポストで、Dropbox は外部ドライブ上の項目に対する symlink をサポートしたことはないとされているが、ひょっとするとそれは変わったのかも知れない。 Google Drive: Google Drive はその場所を変更出来ないと言っているが、Google Drive Help フォーラムでの May 2022 の論議では 、特定の場所に Unix の touch コマンドを用いてファイルを作成することを推奨している。それは、こうすることで Google Drive アプリは File Provider 以前の振る舞いに戻るのだという。
ファイルをドラッグするとコピーではなく移動させる
クラウドストレージサービスの中にはカーネル拡張を使ってローカルフォルダを別のボリュームとして扱うものもある。実際に何が起こるかというと、そのサービスのローカルフォルダへ或いはからファイルをドラッグすると copy 動作につながり、原本を元の場所に残しそして新しいバージョンを目的の場所に作成する。分別のある人はそれが正しいやり方か間違ったやり方かに関して意見は分かれるであろうが、何れにしろ、それがユーザーが慣れ親しんだものである。
File Provider 方式では、全てのクラウドストレージサービスは基本的に内部ドライブ上のフォルダであり、別のボリュームではないので、ファイルを Desktop から Dropbox フォルダにドラッグすることはそのファイルをコピーするのではなくmoves (移動)させることになる。Google Drive から Desktop にファイルをドラッグしても同じことが起こる。
これは重要な変化である。何故ならば、サービスはまたファイルのオンラインコピーも保持しなければならないからで、その結果、少なくとも Dropbox と Google Drive はファイルを Finder の中の別のフォルダに移すことをオンラインバージョンの消去と解釈し、その移動されたファイルをサービスのオンラインゴミ箱に入れてしまう。どちらも何が起こっているかを警告してくるが、その警告をオフにすることも出来る。
ゴミ箱はオンラインコピーを保持するが、ローカルの振る舞いには違いが
では、Finder を使ってファイルをクラウドストレージサービスから消去したらどうなるか？ それには違いがある。私は Dropbox と Google Drive で何が起こるかしか言えないが、Box と OneDrive もこれ等のやり方のどちらかに似たものではなかろうかと想像している。もしそうでなければ、その詳細をコメントに投稿して欲しい。
Dropbox では、そのファイルが offline か online-only かによって異なった動きを見ることになる。offline ファイルをゴミ箱に入れると、それは Finder の中の他のファイルの様に、単純に Trash に移動する。それを戻すことも、別の場所に移すことも、或いは Trash を空にして永久に抹消することも出来る。しかしながら、online-only のファイルを消去すると、Dropbox はそのファイルは直ちに消去されると警告してくる (左下)。Dropbox がその操作は元に戻せないという時、それはそのファイルを Mac の Trash には入れないと言うことを意味している。従って、Command-Z は働かない。しかしながら、どちらの型のファイルの消去も Dropbox ウェブサイト上にある Deleted Files 集合体に移動させる。そこでは、永久に抹消されてしまう前にそこに 30 日間保持される (右下)。
Google Drive にはその様な区別はない。Google Drive にある如何なるファイルを消去しても、offline、online-only に関係なく、他のファイルの様に Mac の Trash に入る。Command-Z を押してその消去を戻すことも出来る。online-only のファイルは Trash の中でもそのクラウドアイコンを維持する。Dropbox と同様、 Google Drive もまた削除されたファイルをそのオンラインゴミ箱に置く。下記のスクリーンショットに、私が削除した二つの ChartOfAccounts ファイルの例を示す。ここでも、削除されたファイルは 30 日間オンラインで入手可となる。
クラウドベースのコンテンツに対する検索は、あまりうまく行かない
ファイルの offline/online-only の状態は検索に影響を及ぼす。意外ではないが、ファイルが online-only の場合、Spotlight がそのコンテンツをインデックスする事は出来ない。しかしながら、Finder ウィンドウでのファイル名検索は働くはずであり、EasyFind や Find Any File の様なサードパーティユーティリティでの検索も働くはずである。
Google Drive はコンテンツ検索に対する簡単な回避策を提供している。Finder の中でカスタムの Google Drive 検索ダイアログを出せる；デフォルトのキーボードショートカットは Command-Option-G である。それは Web 上の Google Drive 上で検索を走らせる。それはまた Google Docs や Google Sheets のコンテンツも見つける。それらが Spotlight に出てくることは絶対にない。何故ならば、それらはローカルドライブ上にはオンラインデータへのポインターとしてしか存在しないからである。
バックアップは働く、しかし...
ここまでくると、皆さんは online-only のファイルは本当に Mac 上には存在していないことをお分かりであろう。つまり、Time Machine や他のバックアップ解はそれ等をバックアップ出来ないのである。Time Machine には全ての Dropbox フォルダ が現れている様に見えるかも知れないが、それ等の中に現れるのは offline ファイル だけである。これに比して、Google Drive のフォルダはそれ等が offline ファイルを含んでいる時にしか現れない。Backblaze は ~/Library/CloudStorage にある offline ファイルを見てそしてバックアップするが、online-only のファイルについては全く知らない。それが下記ではフォルダに二つのファイルしかない理由である。
最初に述べたように、皆さんはクラウドストレージサービスにあるものは全てまずは online-only であり、従って別個にはバックアップされていないものだと想定すべきである。それは自分の関心事ではないかも知れない - 詰まる所、データは全てクラウド内に存在している。しかしながら、他の人達とフォルダを共有しているのであれば、彼らがファイルやフォルダ全体を間違って (或いは悪意を持って) 消去してしまうことだってあり得る話で、結果として共有グループ全員からそれ等を取り除いてしまうことになる。理論的には、それ等はオンラインゴミ箱や Deleted Files 集合体の中で入手可のはずであるが、皆さんはそれに賭けたいとは思わないであろう。Time Machine, Backblaze, Super Duper, 或いは他のアプリを使ったローカルバックアップはその様な間違いから保護してくれる。
その様なことは起こる - Tonya は最近彼女の作業グループの誰かが何週間もの作業を含む大事な Box フォルダを不注意にも消去してしまった。他の回復方法はあったかも知れないが、彼女の Time Machine バックアップからコピーするのは手早く、そして IT サポートに対してチケットを発行して貰う必要もなかった。
と言うことで、十分なディスク容量があるとして、クラウドストレージのデータ蓄積全体を、少なくとも一時的に、ダウンロードすることをお勧めする。全てを手元に置いて、Time Machine や他のバックアップシステムにコピーを作成させよう。その上で、ディスク容量を取り戻したいのであれば、必要としないフォルダを online-only に再設定する。皆さんが作成する新しいファイルは offline となるであろう。何故ならば、それ等は使用中であり、自動的にバックアップに組み込まれる。
ふぅー！ この記事を始めた時、Dropbox フォルダが新しい File Provider 拡張に移行した後どの様に動いたかを説明するのはそんなに長い記事になることはないであろうと思っていた。調査と試験に３日ほど費やした後、私はその詳細はほぼ全て理解したと思っている。しかし、そうではないかもしれない！ もし未だ質問があるのであれば、コメントで聞いて欲しい。
討論に参加
