アカウント名:
パスワード:
なんか変に穿った見方されてるけれど。
ファイルシステムだって、ファイル削除時にデータを実際に0fillしたりして削除するとコスト高いから、削除マーキングするだけなわけで。Appleぐらい巨大なシステム使ってたら、出来るだけ削除なんかにコストかけたくないであろう事は当然じゃないかな。
だから
> ただし、ユーザーがアクセスできないデータをAppleが保持している理由は明らかにされておらず
コスト削減のため、以外に理由あるのかね。ストレージ占有コストの方が高くなったら、いずれ自然に消滅するだろう。
もちろん復元出来るのは問題かも知れないけど、実装自体は別に不思議には思わない。
#個人的には復元可能なのも別に問題とは思わない。#Windowsだってそういう実装だから復元ソフトがあり得るわけで、その実装が問題にされた事なんて今まで見たこと無い。
Apple擁護する気も無く、親コメに概ね同意する。
「完全に削除」は、国家権力が技術を駆使しても復元可能なレベルで削除する事を意味しているとは思えない。裏を返せば最も緩い要件では、情報がサービス外部から完全にアクセスできなくなる事を指していると思う。すなわち管理者であれば情報を復元可能な状況を残していることを含む。保存に寄ったシステムを作ると削除が逆に難しくなる、設計ミスで削除すべき情報が削除できていないなんてのはよくある事だ。
よって要するにこれはバグだと自分は理解する。確かに明らかな事は、AppleのWebサービスの品質がこの程度であるということで、これは揺らがない。
すさまじい自作自演の嵐がスラドにも吹き荒れている・・・！！
僕じゃねぇよ(笑)まあ、証明出来ないから判断はそちらに任せるが。
ていうか、#3216472は
> よって要するにこれはバグだと自分は理解する。確かに明らかな事は、AppleのWebサービスの品質がこの程度であるということで、これは揺らがない。
で別にAppleの品質は大した事ねぇよ、って言ってるじゃない。Xcodeはバグなのか仕様なのかわけのわからん挙動の宝庫なので、僕も同意だけども。
僕もそもそもAppleを擁護したつもりはなく、当たり前の実装の話しかしていない。いい加減に、まともな、論理的な反論をくれ。
信者だろうが信者に対するアンチだろうが、どっちも同じだなマジで。絡まれるとここまで面倒くさいとは。日本語通じているのかい？ 念のためにもう一度言おう。
いい加減に、まともな、論理的な反論をくれ。
インフラじゃなくてアプリの部分では、ファイルのデータをゼロフィルしてからファイルのメタデータを削除するのは簡単かなというのと、日次程度の定期バッチで30日以上古いデータの完全削除をするのは簡単かなって思った。
ストレージ（インフラ）において、ファイルシステムがファイルの削除時にわざわざデータのゼロフィルをしないのは普通の話だけど、このやりとりの有効な範囲を考えたい。ディスクがファイルシステムより下のレイヤで暗号化されている場合（クラウドではこれも普通と思う）、ゼロフィルを意識しなくてもその行為に期待する機能の多く(100%ではない)は果たされているのではないだろうか。
サービスとしては、仮にアプリやインフラがちゃんとしてても、ドキュメントが不整合だと意味がないね。
ああ、やっとまともな返事が……。
> インフラじゃなくてアプリの部分では、ファイルのデータをゼロフィルしてからファイルのメタデータを削除するのは簡単かなというのと、日次程度の定期バッチで30日以上古いデータの完全削除をするのは簡単かなって思った。
僕はバッチというより、クローラみたいなの走らせて負荷の低いサーバから順次消していく、みたいな感じかな、と思った。なので、負荷が集中しているサーバはデータがいつまでも消えなかったりとかもあり得たりしないかな、と。
> ディスクがファイルシステムより下のレイヤで暗号化されている場合（クラウドではこれも普通と思う）、ゼロフィルを意識しなくてもその行為に期待する機能の多く(100%ではない)は果たされているのではないだろうか。
……うーん。物理的なHDD引っこ抜きを想定した話ならその通りだけど、復号化したらそれは結局普通のファイルシステムなので、サービスに接続されている間はやっぱりゼロフィルは必要じゃないかな、と思う。100%ではない、に含んだ話だったらごめん。
> サービスとしては、仮にアプリやインフラがちゃんとしてても、ドキュメントが不整合だと意味がないね。
これはその通り、反論の余地も何もないね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
単にコストの問題では (スコア:1)
なんか変に穿った見方されてるけれど。
ファイルシステムだって、ファイル削除時にデータを実際に0fillしたりして削除するとコスト高いから、削除マーキングするだけなわけで。
Appleぐらい巨大なシステム使ってたら、出来るだけ削除なんかにコストかけたくないであろう事は当然じゃないかな。
だから
> ただし、ユーザーがアクセスできないデータをAppleが保持している理由は明らかにされておらず
コスト削減のため、以外に理由あるのかね。
ストレージ占有コストの方が高くなったら、いずれ自然に消滅するだろう。
もちろん復元出来るのは問題かも知れないけど、実装自体は別に不思議には思わない。
#個人的には復元可能なのも別に問題とは思わない。
#Windowsだってそういう実装だから復元ソフトがあり得るわけで、その実装が問題にされた事なんて今まで見たこと無い。
Re: (スコア:0)
Apple擁護する気も無く、親コメに概ね同意する。
「完全に削除」は、国家権力が技術を駆使しても復元可能なレベルで削除する事を意味しているとは思えない。
裏を返せば最も緩い要件では、情報がサービス外部から完全にアクセスできなくなる事を指していると思う。
すなわち管理者であれば情報を復元可能な状況を残していることを含む。
保存に寄ったシステムを作ると削除が逆に難しくなる、設計ミスで削除すべき情報が削除できていないなんてのはよくある事だ。
よって要するにこれはバグだと自分は理解する。確かに明らかな事は、AppleのWebサービスの品質がこの程度であるということで、これは揺らがない。
Re: (スコア:0)
すさまじい自作自演の嵐がスラドにも吹き荒れている・・・！！
Re: (スコア:0)
僕じゃねぇよ(笑)
まあ、証明出来ないから判断はそちらに任せるが。
ていうか、#3216472は
> よって要するにこれはバグだと自分は理解する。確かに明らかな事は、AppleのWebサービスの品質がこの程度であるということで、これは揺らがない。
で別にAppleの品質は大した事ねぇよ、って言ってるじゃない。
Xcodeはバグなのか仕様なのかわけのわからん挙動の宝庫なので、僕も同意だけども。
僕もそもそもAppleを擁護したつもりはなく、当たり前の実装の話しかしていない。
いい加減に、まともな、論理的な反論をくれ。
信者だろうが信者に対するアンチだろうが、どっちも同じだなマジで。
絡まれるとここまで面倒くさいとは。
日本語通じているのかい？ 念のためにもう一度言おう。
いい加減に、まともな、論理的な反論をくれ。
Re: (スコア:0)
インフラじゃなくてアプリの部分では、ファイルのデータをゼロフィルしてからファイルのメタデータを削除するのは簡単かなというのと、日次程度の定期バッチで30日以上古いデータの完全削除をするのは簡単かなって思った。
ストレージ（インフラ）において、ファイルシステムがファイルの削除時にわざわざデータのゼロフィルをしないのは普通の話だけど、このやりとりの有効な範囲を考えたい。ディスクがファイルシステムより下のレイヤで暗号化されている場合（クラウドではこれも普通と思う）、ゼロフィルを意識しなくてもその行為に期待する機能の多く(100%ではない)は果たされているのではないだろうか。
サービスとしては、仮にアプリやインフラがちゃんとしてても、ドキュメントが不整合だと意味がないね。
Re:単にコストの問題では (スコア:0)
ああ、やっとまともな返事が……。
> インフラじゃなくてアプリの部分では、ファイルのデータをゼロフィルしてからファイルのメタデータを削除するのは簡単かなというのと、日次程度の定期バッチで30日以上古いデータの完全削除をするのは簡単かなって思った。
僕はバッチというより、クローラみたいなの走らせて負荷の低いサーバから順次消していく、みたいな感じかな、と思った。
なので、負荷が集中しているサーバはデータがいつまでも消えなかったりとかもあり得たりしないかな、と。
> ディスクがファイルシステムより下のレイヤで暗号化されている場合（クラウドではこれも普通と思う）、ゼロフィルを意識しなくてもその行為に期待する機能の多く(100%ではない)は果たされているのではないだろうか。
……うーん。
物理的なHDD引っこ抜きを想定した話ならその通りだけど、復号化したらそれは結局普通のファイルシステムなので、サービスに接続されている間はやっぱりゼロフィルは必要じゃないかな、と思う。
100%ではない、に含んだ話だったらごめん。
> サービスとしては、仮にアプリやインフラがちゃんとしてても、ドキュメントが不整合だと意味がないね。
これはその通り、反論の余地も何もないね。