1
2
テーマ、知りたいこと
チェックサムファイルを使わずに、ダウンロードしたファイルがオリジナルと同一であるかどうかを確認する方法はありますか？
背景、状況
ファイルのダウンロード元サーバーでチェックサムファイルを提供していないためです。
当該ファイルがCSVファイル（テキストファイル）なので、確認する方法がないと思っています。
ZIPファイルなど、チェックサムを内包しているファイル形式であれば、ZIPのテストコマンドで整合性の確認は取れることは理解しています。
何か代替策があれば、お知恵をお貸しください。
社内システム間でデータ連携しています。
データの流れは、下記に示す通りシステムA → システムB（★）です。
私は業務システム部門に所属し、システムBを担当しています。
- 情報システム部門のシステムA（サーバー）
- 業務システム部門のシステムB（wgetでシステムAからファイルをダウンロード）
年1回あるかないかの頻度でダウンロードしたファイルが壊れることがあります。
このときはシステム障害となり対応しています。
情報システム部門に、チェックサムファイルの提供を依頼しましたが、なかなか実現しません。
情報システム部門の言い分としては、業務システム部門で発生している問題だから我々に非はない、なぜ情報システム部門が尻ぬぐいしないといけないのか？
とのことで、こういう回答がある時点で、話が進展しません。
情報システム部門と業務システム部門の共通の上位組織の偉い方に解決を依頼しても、現場で解決してほしいと取り扱ってくれません。
最後、愚痴になってしまいましたが、ご回答いただけたら嬉しいです。
追記
ちなみに情報システム部門からの提案は、同じファイルを２回ダウンロードして同じなら成功、異なるのなら失敗しているから成功するまで繰り返す。でした。なぜかとても悲しくなりました。
回答19件
#1
総合スコア145930
投稿2023/09/17 15:27
簡易的な方法としては、「2回ダウンロードして内容が一致するか比較する」ことが考えられます。
元ファイルが壊れたのなら別ですが、ダウンロード中のトラブルでデータ化けが起きた場合、2回とも同じになることはまず考えられません。
#2
#1
ご回答ありがとうございます。
やはり、「2回ダウンロードして内容が一致するか比較する」が現実的ですかね。
これしかないですよね。
#3
総合スコア85766
投稿2023/09/17 18:34
ダウンロード元のファイルサイズが分かっているなら、自分がダウンロードしたのなら、サイズが合っていれば大丈夫です。
ダウンロード途中でエラーで中断することはあり得ますが、最後までダウンロードしたのに一部違うことは無いです。
中断が発生すれば、wgetがエラーメッセージを出したりすると思うのですが、出てないのですかね？プロトコルはhttpですか？もしかしてftpですか？
他の可能性としては、ファイルを作成途中の時にダウンロードしてしまったか。こっちを疑った方が良いかも
社内ネットワーク内の話でなくインターネット上の他サイトからのダウンロードであればいろいろ心配しないといけないこともありますが。
ファイルサイズが不明で、かつ、中味をみても完結しているか分からないのであれば、時間をおいて複数回ダウンロードしてみるくらいしかなさそうです。
#4
#3
ご回答ありがとうございます。
wgetは正常終了ですね。とくにエラーも出ておらず。
プロトコルはHTTPです。
チェックサムファイルを置いてもらうというのは、正攻法な解決策でしょうか？
かなり反発されたので自信がなくなってきました。
#5
総合スコア85766
投稿2023/09/18 00:08
チェックサムファイルを置いてもらうというのは、正攻法な解決策でしょうか？
チェックサム または サイズ ですね。
それより、ダウンロードが失敗する原因究明と対策はしないのでしょうか？
対策できれば、上記どちらも不要です。
年1回あるかないかの頻度でダウンロードしたファイルが壊れることがあります。
とのことですが、どのように壊れているのでしょうか？途中で切れている？中味が全然違う？
「うまく行くケースと条件を全部比較しても条件が全部同じで、再現テストしても再現しない」ところまではやってますか？原因なく壊れることはないので、必要な情報が全部取れてないなど、調査が足りないのだと思いますが。
ただ、「元ファイルがその時点で壊れていた」かどうかの調査は自部署だけでは判明しないですね。
#6
総合スコア141
投稿2023/09/18 02:23
wgetでHTTP通信とのことですが、HTTPSではなくHTTPでしょうか？
HTTP通信はTCP/IPの16bitチェックサムとイーサネットの32bitCRCしかない為、稀に電文化けしてすり抜けることがあります。
HTTPS通信であれば鍵長が長いためそのようなことは起こりません。
可能であればHTTPS通信としてはどうでしょうか。
またチェックサム値を返すcgiやphpなどのスクリプトをサーバ側に配置し、サーバ側で計算したものを返して、ファイルダウンロード後に比較するという手法もあります。チェックサムファイルがサーバに置いてあるより、私はこっちの方法が好きです。
#7
#8
総合スコア2022
投稿2023/09/18 07:12
チェックサムが正攻法か否か。技術的には一つの正しい方法ではありますが、今回は技術的な話ではなく依頼元の政治力不足で断られていると想像されますので、それを突き詰めてもしかたがないのでは。
逆に同じファイルを2回ダウンロードするのがなぜダメなのか気になります。わたしはその案でもいいと思いますけれども、なぜダメなんですか? 説得力のある説明ができるならチェックサム案に倒れるかもしれませんし、「なぜかとても悲しくなりました」としか言えないなら難しいのでは。
#9
総合スコア85766
投稿2023/09/18 10:00
HTTP通信はTCP/IPの16bitチェックサムとイーサネットの32bitCRCしかない為、稀に電文化けしてすり抜けることがあります。
なるほど。仰るとおりですね。失礼しました。サイズのみでOKを撤回します。
異なるレイヤーでそれぞれチェックしている物をどのようにすり抜けたら通るのかを考えるのが難しそうで、直感的にどれくらいの確率になるのかよくわかりませんが。「原因不明で再現性無し」だとこのケースと考えるのですかね。
これが原因なら、2回でコンペアで十分そうです。質問の状況からWAN経由ではないのではと思うので、仮に巨大ファイルでも2回ダウンロードを許容出来るのではと思います。
#10
総合スコア1089
投稿2023/09/18 13:29
思いつきですがrsyncが使えれば解決しそうです。
#11
総合スコア204
投稿2023/09/21 02:30
どこまでの作業権限があるのかわからないのですが独自の型式を定義すればいいと思います。
CSVを内包したフォーマットを定義した上でChecksumも一緒に内包してしまえばチェックサムファイルもいりません。
ファイルアップロードとダウンロードをする実装を自力でコーディングできればの話になりますが・・
私はゲーム屋なのでセーブデーターなどのフォーマットをよく作ったりするのですが
こんな感じのフォーマットを雑に定義して、JsonをPurseしてPurseに失敗したら
再ダウンロードをリトライを実施。
Purseに成功してさらにチェックサムが一致してなければリトライ、一致してたらダウンロードを完了みたいなことをしてます。（もっとちゃんとしたシステム開発ならまともなやりようがあると思うがこれで大体困らんので・・・）
json
1{ 2 "md5_checksum": xxxxxx, //CSVのチェックサム 3 "raw_csv_text": "xxxx", //CSVテキストの生データ 4}
なんならファイル名に直でチェックサムの値を入れちゃってもいいんじゃないですかねWindowsのファイル名最大長は256文字ですがMD5なら32文字とかですからね。 SHA256でも64文字なので多分格納可能だと思います
#12
総合スコア125
投稿2023/09/21 09:44
通信経路品質の問題のような気もしますけれど、この手の問題で「どちらかだけが悪い」ケースってあまりない気がしますね。
技術的問題というよりも、多分に政治的問題、という気がします。
インフラ屋としては、サバクラモデルでのネットワークデータ破損でサーバ側が「完全に非がない」なんて両面から厳密に調査でもして原因がはっきりわかってないととても言えませんが…ということはさておき、問題解決に対してサーバ側が非協力的である、と考えた場合。
状況的には情報システム部提供のCSVデータと考えられ、アップロードが別口から行われる、あるいはサーバ内生成の可能性が高いのかな、と思います。
この仮定だとアップロード時点にハッシュ紛れ込ませる手は使いにくいかもしれないですね。サーバ側が非協力的ならサーバ側に何か変更を加える手もアウト。
現実解なら確かに多重ダウンロードでのサイズとチェックサムコンペアが手っ取り早そうです。別プロトコル使いたくても、結局それを用意しなければならなくなるのは情報システム側で、チェックサム計算すら嫌がっている側が何か動いてくれるとも思えません。
結局クライアントだけで対応できる範囲、となると十分に現実解ですね。機械処理化するのもそこまで苦労するものでもないですし。
悲しい気分はなんかやってることがバカバカしいとお思いなのかもしれませんが、目的を達成できない理想論より、目的が実現できる現実解、だと思います。
調査的にはクライアント側が試せることとすれば使っているHTTPクライアントのライブラリをいろいろ変えてみるとか、パケット拾うとかですかねぇ…枯れた技術なのであまり変なバグもないとは思うんですが。HTTPですし化けるときは化けますよねぇ…。
※イントラはいまだにFTP信じてる人も多いですし。
権限絞ったSSHアカウントくださいよ、ってお願いしていただけるのであれば、かなり選択の幅は広がるのでしょうが、管轄外の部署にサーバいじられたくない、という心理は働くでしょうからsshもくれなさそうな気配が香ってきますし、ほかに有効な手段はあまりないようにお見受けします。
#13
総合スコア4443
投稿2023/09/23 06:56
編集2023/09/23 07:14ほかのかたがたの意見と同じなのですが、特定ファイルのダウンロード以外のサーバ操作を認められていないのだとしたら、ダウンロード操作だけでできる確認方法を取るしかないでしょう。
それと、ちょっと気になったのですが
年1回あるかないかの頻度でダウンロードしたファイルが壊れることがあります。
このときはシステム障害となり対応しています。
ということは、ダウンロードしたファイルの内容の正常性を確認しないままシステムに食わせているということでしょうか。
もしもそうなら、正常性確認のステップを入れるようにすれば、対応が必要なくなりはしないものの、大事になる前に再ダウンロードなどの対処ができるはずです。また、データの破損が起きたことを証跡として残すことで、将来情報システム部門と交渉する機会が訪れたときに多少は有利な立場に立てることもあるかもしれません。
[付記] ダウンロード時に壊れると想定しておられる様子ですが、アップロード時や、すでにデータ作成時に破損している可能性だって現時点では排除できないですよね。調査していない (できない) ですから。ダウンロードが正常に行えているか否かにかかわらず、データの正常性確認は有益だと思います。
#14
総合スコア85766
投稿2023/09/23 15:23
ダウンロード時に壊れると想定しておられる様子ですが、アップロード時や、すでにデータ作成時に破損している可能性
普通だと可能性としてはそちらの方が大きいので、#5 で指摘しているのですが、#7 で「後で対応」というのが質問者の直近状態です。
どのように壊れているのでしょうか？途中で切れている？中味が全然違う？
・作成途中で途中まで分をダウンロードしてしまった
・作成前に前回分をダウンロードしてしまった（この場合だと「壊れていた」とは書かないだろうから違うか）
・提供側で、作成ミスで異常なファイルを作り、後で上書きされた（普通は連絡がありますがこの組織だと？？）
などが想定されます。
#15
総合スコア300
投稿2023/09/25 09:07
１年に１回だと、原因究明も大変ですね。
wgetでエラーなしだと、
wgetってダウンロード中も名前同じで、ダウンロード中のファイルにアクセスしてしまってる可能性はないですか？
また、別にフォルダにダウンロードしてコピーもコピー中にアクセスされるとか、ないですか？リネームして切り替えてますか？
#17
総合スコア756
投稿2023/10/01 23:30
ちなみに情報システム部門からの提案は、同じファイルを２回ダウンロードして同じなら成功、異なるのなら失敗しているから成功するまで繰り返す。でした。なぜかとても悲しくなりました。
これでは同一性は保証できません。
中間者攻撃やファイル中のbitが反転した場合は検出できません。
ファイルの整合性を確認するためにはチェックサムを提供してもらうのが良いと思います。
もちろん、チェックサム自体の取得の際にファイルが壊れる可能性もありますが、その場合は不一致となって問題を検出できます。
npmにおいても、ファイルの同一性を保証するためにはファイルのチェックサムを使っているので、チェックサムに寄る検証が一般的かと思います。
#18
総合スコア85766
投稿2023/10/02 10:58
これでは同一性は保証できません。
保証のレベルによりますが、「ダウンロード中に、通信中の各ネットワーク階層で短く区切った単位でのチェックサム比較で検出できないレアな確率でのエラーによるデータ化け」が無いことの保証という意味では、ファイル全体のチェックサムよりは確度が高いでしょう。
ファイル中のbitが反転した場合は検出できません。
2回ダウンロードコンペアで検出できないという話であれば、送信側の元々のファイルがおかしかった可能性の話ですかね？
それについては、どう考えるかを質問中で、質問者の確認待ちです。#16
中間者攻撃や
社内システムのデータに対しての中間者攻撃というのは考えにくいです。技術的にもですが、中間者攻撃をしようという動機の面。業務妨害の悪意があればもっと他の手段が楽。
中間者攻撃を想定する場合でも、「攻撃者はデータ本体は差し替えるが、チェックサムファイルは絶対に差し替えない」という妙な想定でもしない限りは、チェックサムファイルも信用できないので、チェックサム比較は保証になりません。
ミラーサイトが多数あって、「サイトAから本体をダウンロードして、サイトBのチェックサムファイルと比較する」であればともかく（これはどっちかというとサイト改竄対策ですが）。
#19
退会済みユーザー
総合スコア0
投稿2023/10/05 00:42
編集2023/10/05 08:32送られたものが正しいことと、ダウンロードされたファイルがhttpsで送られたものであることを保証できており、httpsの伝送を信じられるのであれば、所定の量が送られていれば同一だと思っていいのではないかと思います。
chunk転送であればそれが正しいこと、そうでなければContent-Lengthが付いていて、ファイルサイズと一致していることで所定の量が送られていることになるのではないかと思います。
よく読んでませんでした。httpなようですね。
社内システムであれば、俺がやる！って言ってササっとuploadスクリプトを入手してchecksum付きにして返せばいいのではないかと思います。
あんまり小さなファイルだったり、開発用のモノなのに過分なチェックをしてるとかだと、こだわりを押し付けてるだけと思われて反発されるかもしれませんけど…
向こうも必要だと認識してるけど手が回らないだけなら悪い顔はしない気はします。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。