［緊急］iTunes 2.0 for Mac OS X　被害者の会

これは、Apple にとって地獄への踏切板かも

・経済的に補償する
　経営悪化。

・経済的な補償はしない。
　大量の顧客離れ。Digital Hub 構想は笑いのネタに。

ポセイドンさんのところにその瞬間の動画がおいてあるけど、すごいね、なんか。
ttp://member.nifty.ne.jp/poseidon/index.html

デスクトップを動画キャプチャなんて出来るんだ。
知らなかった・・・

>>832
まさに瞬殺。使用許諾もでないね。

>>832
Installer.appが、iTunes2インストーラーの問題のような
インストールスクリプトの不具合を解決するInstaller.appが
出るまでは同じような過ちがいつ何時あってもおかしくないわけだ。
このことの危険性をもっと考えてもいいと思うのだが...

>>833
Snapz Pro使えば動画キャプチャー撮れます。

>>835
でもさ、iTunes2みたいなのはスクリプト側の問題なので、
インストーラーアプリ側でどうにかできるような問題でも無いように思うんだよね。

今の構造（Unixのシェルスクリプトを内部で呼び出してる）が変わらない限りは。

WTCの時にはトップページに追悼の言葉が掲載されたけど、
肝心の自分ちのユーザーへのテロについてはほとんどなしかよ。

トップページに正々堂々と掲示してほしかった。
そうすれば、今回のトラブルも多少は良い方向に行っただろうに.....。

幸い被害には遭わなかったけど、こんなアフターサービスでは不安倍増。
隠ぺいするのって、100%悪い方向に行くよ。

嘘は絶対にばれるよね。いつかは。
特に、二人以上の人間が絡むとすぐばれる。

ある意味、事故やミスは避けられませんが、その後の
対応はいくらでもコントロール可能。それを誤ると、
被害は拡大していきます。

私はたまたまiTunes2をｲﾝｽﾄｰﾙしませんでしたが、数日
遅かったらアウトでした。私の環境ではアウトでしたから。
（ﾊﾞｯｸｱｯﾌﾟ後、確認してみました。）

みなさん、今後のＡＪの対応をしっかり見ておきましょう。

嘘逝っているという意味ではなく、問題ごとはいつか
ばれますよ〜という意味です。

>>837
厨房でスマソ。まだOS Xのことよく分かってないんだけど...
このインストーラーアプリ使ってソフトウェアアップデートされる
ことないの？
自動的にハードディスクの中身消されちゃったらやだなと思って...

>>841
書いたようにインストーラーアプリ側の問題じゃないからね、
ソフトウェアアップデートでダウンロードされたファイルの
インストーラースクリプトにiTunes2と同様の不具合があれば、
同じようにハードディスクの内容が削除されてしまう可能性はある。

>>842
そうなんだ...
>>790のシェルのエイリアスがどうたらってのすれば回避できるの？
もし出来るんだったら詳細教えてください。

842,843<<
ということは、悪意のあるスクリプトを書いて、
「ごめんなさい、ミスでした」という仕業が、
アップル以外でも可能だということ？

>>843 844
残念ながら回避することは難しいと思う。
844が心配しているように、これを悪用したトロイの木馬を
作ることだってできる。

Mac OS Xでは通常、システム関連の重要なファイルや、他のユーザー
のファイルは削除したり移動したりすることはできなくなっている。

でも、インストーラー起動したときに管理者パスワードを入れるだろ。

あれはインストーラープログラムに管理者権限を与えているわけだ。
管理者の権限があれば、システムファイルや他のユーザーの
ファイルの削除もできる。

だから、悪意のあるユーザーが、一見すると便利そうに見える
ソフトのインストーラーに偽装して、環境を破壊しまくる
ソフトを作ってばらまくことも可能だ。

まぁ、これはMac OS Xに限った話ではなくWindowsでも
似たようなことはできるから、よく言われることだが
出所のはっきりしない、怪しいソフトのインストールは危険
だってことだな。

今回のiTunes2のように、悪意でなくミスだった場合は
防ぎようがないが。

Appleが決めることではあるが，

rmコマンドの仕様変更で回避は出来ないだろうか．
結局，rmコマンドで瞬殺されちまったのが今回の敗因なのだから．

>>846
消す前に「○○を削除します」というようなアラートが出るようなプログラムにしたら
どうでしょ。漏れ、プログラミング分からないんであれだけど、削除する対象を示している
部分と同じところをアラートに表示するように指定したら、できるような気がするんだけど。
そういうアラート入れれば、逆に言うと、古いアプリを置いておけるわけで、
新しいアプリで不具合が出たときに戻りやすかったりもするし。

なんだこの議論は・・
所詮マカにUNIXなんて死ぬまで無理か
Apple社ですら無理がたたってこんなこと
やらかしてるしな・・

>>847
技術的には可能。

でも、たとえば今回のiTunes2のバグなら通常は
「/Applications/iTunes.appを削除しますか？」
みたいなダイアログが出るところが、
「/Volumes/を削除しますか？」というダイアログになるので、
そこで「何かおかしい」と思ったユーザーはキャンセルするだろう。

しかし、通常は/Volumesというディレクトリはユーザーから
不可視になっているので、初心者ならよく分からないまま
「OK」をクリックしてしまう危険性はある。

ところで>>1は新しい続編スレを立てる気なのだろうか・・・

>>844-845
そうか、Appleでも（？）おこすようなミスをサードパーティーが
犯してしまうこともありえるわけだな。
Adobeなんかがこんなインストーラーばら撒いたらどうなるんだろう...
ちょっと興味あるな。ユーザーの反応とか会社の反応とか。

ttp://slashdot.jp/article.pl?sid=01/11/08/0131236&mode=thread&threshold=

>>837
容量も出たらいいかも．
「/Volumes/（12.5GB）を削除しますか？」とか．
さすがに超初心者でなければ気が付くかも．

>>853

でもそういう方向で進めると結局Windows的になっちゃうんだな。やたらに
うざったいダイアログが出てくるという。通常通り古いバージョンのアプリ
を削除する場合でも、初心者は本当にそれを削除していいのか悪いのか、
少なからず混乱して悩んでしまうという点でユーザビリティーに欠ける。
個人的にはやはり基本的なシステムの安全性を高める工夫を求めたいところ。

Macユーザーは忙しい

rmコマンドの変わりにコマンドラインからゴミ箱にいれるtrashと言う
コマンドをAppleがつくって、自社、及びサードパーティに配付すれば、
いい（たしか、Linuxであったはずだが？）。そうすれば、最悪、別パ
ーティションから起動すれば、ファイルはたすかる。もちろん、第3者
検証、評価のため、オープンソース、他のLinux,UNIXコミュニティ用
のも、作成するのがのぞましい。いずれにせよ、Installer作成者、
ユーザーは必ずミスをおかすものとして、ソフトをつくらなければ、
やばい。

＞＞に配付すればいい
使う用奨励すれば、のまちがい

>>853
なるほど。
まあ、それでも気付かないヤツは気付かないんだろうけどね。

>>856
確かに、Finderでのファイル削除は本当に削除するのではなく
Trashフォルダに移動するだけなのに対し、rmコマンドは
即座に削除しちゃうから、今回のような場合に被害が増大する
結果になったともいえるね。

わざわざ作らなくともインストールスクリプト中ではrmを使わず
mvでtrashフォルダに移動させるようにガイドラインを作って
おけば良かったのかもしれない。

ただ、こういうのはなかなか徹底させるのが難しいのだが。

>>856
善意のユーザと開発者相手だけなら確かにそれでカタはつくと思います．
UNIXの堅牢さとクラシックなMacOSのユーザビリティを併せ持つシステム
を目指すなら不十分ではないでしょうか．

#ってTell Us向けだな．
#仕事でUNIXも使っちゃ居るが，UNIXの流儀をここまで持ち込まれてもねぇ．

rmの仕様変更って・・・
アホが -rf 付けてるのがまずかっただけじゃん。

俺、UNIX は全然分からんが
インストーラに危険な記述がないか
スキャンできるようなソフトーウイルス検知ソフト
見たいなもんって作れないの？
人間はミスするし、悪意の人間もなくならん
自己防衛しかなっいしょ

>>859
mvなり、trashは、バックエンドで走るとして、フロントエンドの
GUIの表示上は、「インストールの処理中に旧バージョンのファイル等
いらないとおもわれるファイルをゴミ箱にすてました。もし、その中か
らいるものがあれば、ゴミ箱からひらってください。」と言う表示を出
せばいい。

>>860
.app は実際のファイル構成上はディレクトリ扱いやから、
-r がないと消せんし、インストーラはroot権限で実行されるそうだから、
-f はあってもなくても結局消されるんじゃないかね？

そもそもUNIX風の確認表示は、インストーラ上でGUIダイアログとして
なされるもんなんかな？

普通のシェルスクリプトでは、まず中のファイルを消してから、
ディレクトリを消去するもんでは？
中身を確認せずにrm -rでばっさり消すのは危険。

UNIX風に言えば、確認メッセージも出力の一形態なんだから、
コンソールに出力しようが、ダイアログに出力しようが、/dev/nullに出力しようが、
どれでも好きにやっていいでしょ。

aliasでrmをrm -iにしてもrm -fすると確認無しで消されるね。

あぁくだらねぇ。面白いねただと思ってよんでたけど730位まででレス読むのやめたよ。
もちろん、俺もまかだよ。
俺も7.52でひどい目にあった口だ。
それにくらべたら今の大容量HDだと当人の被害はでかいだろうな。
だけどさ、本当に大事なデータなら常にバックアップをとるなりボリュームをあんまうんとするのは常識だろ？

ほんと人柱御苦労さん。
訴訟なりクレームでなんかもらえたとかいいことあったら教えてくれ
俺もバックアップとった上で同じ事してアップルこまらせてやるから。

ところでNEXT時代のインストーラーには
この手の問題ってなかったんですか？

>>867
無かったよ。やはり、無理矢理MacOSと統合したのが祟っているのかな。
まあ、OS Xは新規OSだから、ばーぢょん3位までは大目に見ないと。

おっと言い忘れたよ。
ituneなんてお遊びアプリ、なんでそんなに慌てて当時の最新版を
入れる必要があるわけ？そこらへんが謎。

>>869
過去ログ読め

>>869
で、職種は？

負け犬ってほとぼり冷めた頃必ずまたレスするよねｗ

エラーが出てインストール出来ないのは漏れだけ?

まとめが出たのであげ
http://member.nifty.ne.jp/poseidon/itunes2.html

>>847
一件落着ですな。

＞以下のいずれかの条件を満たす場合：
＞(1) マウントしているボリューム（起動ディスク以外）の中に、名称に空白を含むボリューム(A)が存在する。
＞かつ、ボリューム(A)の名称の空白以前の文字列と一致する名称の別のボリューム(B)が存在する。
＞(2)マウントしているボリューム（起動ディスク以外）の中に、名称の先頭が空白文字であるボリューム(C)が存在する。
＞(3)マウントしているボリューム（起動ディスク以外）の中に、同じ名称のボリューム(D)が複数存在する。
＞
＞現象：
＞(1) ボリューム(A)の名称の空白以前の文字列と一致する名称の別のボリューム(B)が存在する場合、ボリューム(B)の内容が削除される。
＞(2) ボリューム(C)の名称の先頭が空白文字の場合、マウントしている起動ディスク以外のボリュームの内容が削除される。
＞(3) 複数の同一名称ボリューム(D)が存在する場合、そのうち一つのボリュームの内容が削除される。

TidBITSで今回のことが掲載されています。
ttp://www.tidbits.com/tb-issues/lang/jp/TidBITS-jp-605.html

緊急あげ

一応一段落かな、

一段落したというより、被害者は泣き寝入りするしかなかったのだろう。
実際、AJに連絡しても、うちは関係ないとぬかすし、Incの方にメール
出しても返事こないし。
一部報道のあったストレージ代金の返却なんてのはどこまで適応されたか
不明ですし。
今回の件を教訓に各ベンダーが不具合をださないようになればいいですね。
個人的にはマウントしたままのHDはバックアップとはいえないというのが
最大の教訓かも。

今年一年のApple十大ニュースのトップだったりして