アカウント名:
パスワード:
新潟県データ10万件消失事故 拡張子を小文字にしたかったのはなぜか 県に聞いた [itmedia.co.jp]
こんなのマクロ側をなおせばいいのに...おもしろいことをするなぁ。
データ削除プログラムは、登録されたファイルのリストを参照してリストにないファイルを削除する仕組みだという。新機能により拡張子が変換されたことで、該当ファイルの名前がリストに記載されていないことになり、10万件のデータが削除されたとしている。
面白いというか謎仕様だ。ファイル名をちょっとでもいじったら消されるの？ この件、不思議な仕様と経緯だらけ。
「登録されたファイルのリスト」ファイル登録時にリストを生成して、勝手に変更されたら改変されたと見做して削除するという仕様なんすかね。後付のツールが勝手にファイル名を変更するというのは想定できないでしょうし。
改修するとしたら・ファイル名やタイムスタンプ変更が見つかったら、ファイルを隔離してアラーム上げる・作業履歴を確認して、廃棄 or renameして戻すかどうかを判断とかかな
ストレージの空きを確保するためのガベージコレクション的な奴かと。参照されてないから不要として削除したけど、実は使用中だったと。
ガベージコレクションは使用中の奴は削除しないぞ。
この件については、まだ使ってるのを削除してしまった単純なバグでしょう。メモリリークの逆。
文書管理(使用中ファイルの管理)は case sensitive だけど、ファイル名の大文字小文字を変換したから、ガベコレから見ると使用中扱いじゃなくなった、ってことじゃないかな。
ファイルシステムは case insensitive なら、ファイル名の大文字小文字の変更は問題ないので、ガベコレのバグ。
case sensitive なファイルシステムを使っているなら、今回導入したファイル名変換ツールがファイル管理の整合性は取ってなかった、というファイル名変換ツールのバグ。こっちだとすると、たとえファイル削除してなくても、「文書管理ツールからファイルが見えなくなる」って問題が起きるかな。
ファイルを登録するときにDBに書き込み、同時にファイルを作成する。ファイルを読みだすときはDBで検索して、その情報に基づいてファイルを取得して返す。不要ファイルの削除をするときはDBの該当ファイルの情報を消し、のちにバッチ処理でDBに載っていないファイルを消していく。そんな処理になっていたんじゃないですかね。DBにはメタ情報が入っていて、普段をそれで該当ファイルを探してダウンロードするシステムであると考えれば、それほどおかしな設計ではないと思いますよ。
あるかどうか不明な削除対象ファイルを探すために全ディレクトリをスキャンするのはなんかダサいな最初はずっと余裕だと思っていたストレージが足りなくなってきて、その場しのぎで作った容量確保処理をそのまま常用することになったみたいな感じだろうか
あるかどうか不明な削除対象ファイルを探すために全ディレクトリをスキャンするのはなんかダサいな
ダサいかどうかは別として、例えばよく使われるPHPとその標準ライブラリーなら数行で記述可能です。ほかの処理系でもそういったものはきっとあるでしょう。
ストレージが足りなくなって
おおもとでファイルと書いていたのでローカル・ストレージの可能性をもって書きましたが、もしかするといわゆる「オブジェクト・ストレージ」系の可能性もありそうです。その場合は少しだけ違う処理をしている可能性もありそうです。容量については要求仕様によるので、実装側の責任問題にはこの場合にはなりにくそうに考えますが、いかがでしょうか？
だせえよ。俺ならそんなん一行だぜ
# rm -rf /*
クソ仕様な気がしています。（しかも高額かも）
もっと普通な仕様を提案できるチャンスなのかも。
バックアップ世代管理が３日間というのも時代遅れを感じます。
想像だけど、単なるファイルサーバじゃなくて、公文書管理ならあり得ると思う。保管文書にどのようなファイルかは把握しないといけない、変な文書がおかれては困る、保存期限も管理しないといけないとか、いろんな条件があるだろうから、リストで一覧が管理されていて、実装はともかくとしてリストに無いものは削除という仕様は当然と思う。
マクロ側を修正するお金がなかったんでは。一方、DB側の変更は既存の開発・保守契約の範囲内で納められるとか？
# まあ普通はDB側はいじらないよな、、影響する範囲を見積もるだけでもたいへん。
ITmedia
（県は）「拡張子が大文字なのは仕様なのか」という趣旨の質問をしたという。（途中経過謎）「仕様を尋ねたのは確かだが、改修をお願いしたかは確認中」
仕様を尋ねて、「どうしたらいいの？」か、「何とかならないの？」とか、ボソッと言った感じ？ もちろん、何も言ってない可能性もある。富士電気側が解決策を模索して試してみて、ああこれでいいや、で正式のゴーサインや協議を怠った感じ？ 富士電気は「保守担当者の人為的ミス」としか発表していない。
影響範囲を見誤ったらこういう問題やらかすわけだしな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
追加情報 (スコア:1)
新潟県データ10万件消失事故 拡張子を小文字にしたかったのはなぜか 県に聞いた [itmedia.co.jp]
こんなのマクロ側をなおせばいいのに...
おもしろいことをするなぁ。
Re:追加情報 (スコア:2)
面白いというか謎仕様だ。ファイル名をちょっとでもいじったら消されるの？ この件、不思議な仕様と経緯だらけ。
Re:追加情報 (スコア:1)
「登録されたファイルのリスト」
ファイル登録時にリストを生成して、勝手に変更されたら改変されたと見做して削除するという仕様なんすかね。
後付のツールが勝手にファイル名を変更するというのは想定できないでしょうし。
改修するとしたら
・ファイル名やタイムスタンプ変更が見つかったら、ファイルを隔離してアラーム上げる
・作業履歴を確認して、廃棄 or renameして戻すかどうかを判断
とかかな
Re: (スコア:0)
ストレージの空きを確保するためのガベージコレクション的な奴かと。
参照されてないから不要として削除したけど、実は使用中だったと。
Re: (スコア:0)
ガベージコレクションは使用中の奴は削除しないぞ。
この件については、まだ使ってるのを削除してしまった
単純なバグでしょう。メモリリークの逆。
Re: (スコア:0)
文書管理(使用中ファイルの管理)は case sensitive だけど、
ファイル名の大文字小文字を変換したから、
ガベコレから見ると使用中扱いじゃなくなった、ってことじゃないかな。
ファイルシステムは case insensitive なら、
ファイル名の大文字小文字の変更は問題ないので、
ガベコレのバグ。
case sensitive なファイルシステムを使っているなら、
今回導入したファイル名変換ツールがファイル管理の整合性は取ってなかった、
というファイル名変換ツールのバグ。
こっちだとすると、たとえファイル削除してなくても、「文書管理ツールからファイルが見えなくなる」って問題が起きるかな。
Re: (スコア:0)
ファイルを登録するときにDBに書き込み、同時にファイルを作成する。
ファイルを読みだすときはDBで検索して、その情報に基づいてファイルを取得して返す。
不要ファイルの削除をするときはDBの該当ファイルの情報を消し、のちにバッチ処理でDBに載っていないファイルを消していく。
そんな処理になっていたんじゃないですかね。
DBにはメタ情報が入っていて、普段をそれで該当ファイルを探してダウンロードするシステムであると考えれば、それほどおかしな設計ではないと思いますよ。
Re: (スコア:0)
あるかどうか不明な削除対象ファイルを探すために全ディレクトリをスキャンするのはなんかダサいな
最初はずっと余裕だと思っていたストレージが足りなくなってきて、その場しのぎで作った容量確保処理をそのまま常用することになったみたいな感じだろうか
Re: (スコア:0)
ダサいかどうかは別として、例えばよく使われるPHPとその標準ライブラリーなら数行で記述可能です。
ほかの処理系でもそういったものはきっとあるでしょう。
おおもとでファイルと書いていたのでローカル・ストレージの可能性をもって書きましたが、もしかするといわゆる「オブジェクト・ストレージ」系の可能性もありそうです。
その場合は少しだけ違う処理をしている可能性もありそうです。
容量については要求仕様によるので、実装側の責任問題にはこの場合にはなりにくそうに考えますが、いかがでしょうか？
Re: (スコア:0)
だせえよ。
俺ならそんなん一行だぜ
# rm -rf /*
Re: (スコア:0)
クソ仕様な気がしています。（しかも高額かも）
もっと普通な仕様を提案できるチャンスなのかも。
バックアップ世代管理が３日間というのも時代遅れを感じます。
Re: (スコア:0)
想像だけど、単なるファイルサーバじゃなくて、公文書管理ならあり得ると思う。
保管文書にどのようなファイルかは把握しないといけない、変な文書がおかれては困る、保存期限も管理しないといけないとか、いろんな条件があるだろうから、リストで一覧が管理されていて、実装はともかくとしてリストに無いものは削除という仕様は当然と思う。
Re: (スコア:0)
マクロ側を修正するお金がなかったんでは。
一方、DB側の変更は既存の開発・保守契約の範囲内で納められるとか？
# まあ普通はDB側はいじらないよな、、影響する範囲を見積もるだけでもたいへん。
Re:追加情報 (スコア:2)
ITmedia
仕様を尋ねて、「どうしたらいいの？」か、「何とかならないの？」とか、ボソッと言った感じ？ もちろん、何も言ってない可能性もある。富士電気側が解決策を模索して試してみて、ああこれでいいや、で正式のゴーサインや協議を怠った感じ？ 富士電気は「保守担当者の人為的ミス」としか発表していない。
Re: (スコア:0)
影響範囲を見誤ったらこういう問題やらかすわけだしな