アカウント名:
パスワード:
データのコピーに成功してベリファイも出来たのでオリジナルを消したら、その後のファイナライズにコケた、とか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ムーブに失敗しないコピーワンス (スコア:1)
規格規定上バックアップを持つことは可能ですし、要求仕様も「再生不能化」であって「消去」ではないですから、
障害時にはリカバリかけられるような保険を仕込んでおけばそんなに難しいことではないと思います。
実際、一部のメーカの機器はそのあたりを活用してるようですね。
# さすがにムーブが何らかの要因で止まること自体を「失敗」と称するなら無理でしょうが。
# 途中でiLinkケーブル抜かれたり、コンセント抜かれても実行し続ける自信はありません :-)
なお、このあたりの仕様が緩和されたのは運用開始後の改版などですから、初期はムーブ失敗ってよくありましたし、
今でも一部の「未熟な」連中が設計したり、コストけちられたりした機器では相変わらず失敗するようです。
そのあたりで一部では都市伝説化している部分は否めないですね。
> こちらには“未熟”ではない優秀な技術者の方が大勢集っていると思いますが、
> 『ムーブに失敗しないコピーワンス』が可能になる解をお持ちの方はおられるでしょうか?
優秀とまでいかなくても普通の技術者であれば、要件分析段階で規格書とか確認すると思いますので、
前述のような仕様を活用することを考えられると思います。
泥臭くバックアップの取り回しをするくらいは(私ですら)簡単に思いつきますが、
それではつまらないので、エレガントな設計案をぜひ。
# 直感的には「再生不能化」要件活用して暗号鍵の取り回しでやるのがよさそう。
Re:ムーブに失敗しないコピーワンス (スコア:1)
データのコピーに成功してベリファイも出来たのでオリジナルを消したら、その後のファイナライズにコケた、とか。
Re:ムーブに失敗しないコピーワンス (スコア:2, 興味深い)
(DVD-Rのように)ムーブ先がファイナライズしなくても再生可能であるのであれば、
「ファイナライズ」自体がムーブ処理の後工程ではないため、それはそもそも「ムーブ失敗」ではないのでは。
録り貯めていたDVD-Rをファイナライズしたら失敗してオシャカになった、というのと同じ話ですね。
# コピワンがなければマスターデータがあったのに...という気持ちはわかります :-)
また、ファイナライズしないと再生可能にならないようなメディアを想定しているのであれば、
オリジナルを「再生不能」にするタイミングをファイナライズ完了の応答が確認できてからにするべきでは。
そもそも求められているのは「消去」ではなく「再生不能」ですし、バックアップ作っておく手もあるんで、
最後の保険としてファイナライズ失敗を検出した時にリカバリ処理で救う手段を用意しておけばいいだけかと。
# 「再生不能」に対してのクラックリスクを回避するために一定の対タンパ性は必要になるかと思います。
もともと一定の保護下にあるフォーマット間でのやり取りですから、
「再生不能化」は「消去」ではなく「鍵とデータの紐付け」でコントロールできるわけですしね。
Re:ムーブに失敗しないコピーワンス (スコア:1)