ファイルの重複検出ツールを作ろうぜ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2007/10/18(木) 17:20:10初めに64KB程度読み込んでハッシュを計算して、それが一致したら1MB程度ぶんずつ照合していく
ハッシュの計算方法は高速で、異なるファイルは異なる値を出すようにしたい
いちどブロックソーティングするといいとおもう
0002デフォルトの名無しさん
2007/10/18(木) 17:22:160003デフォルトの名無しさん
2007/10/18(木) 17:25:02解説サイトをあげておきます
http://www.geocities.jp/m_hiroi/light/pyalgo48.html
http://www.01-tec.com/document/basic_compression.html
http://ja.wikipedia.org/wiki/Burrows-Wheeler%E5%A4%89%E6%8F%9B
http://homepage3.nifty.com/DO/blocksorting.htm
0004デフォルトの名無しさん
2007/10/18(木) 17:33:360005デフォルトの名無しさん
2007/10/18(木) 18:13:35この巡回データ （1101 1011 0111 1110）をソートするわけですが、
これを10進に直すと 13 11 7 14 です
配列を16個用意して、13番目に1、11番目に2、7番目に3、14番目に4を代入してその他は0とします
先頭から1以上の数字を読み込むと、3 2 1 4になりこれでソートが完成します
初めに与えられた2進数の幅が大きい場合は、ランレングス圧縮 して登録するとよさそうな気がします
0006デフォルトの名無しさん
2007/10/18(木) 18:47:0710101010101010101010101010とかのデータが出てきた場合
どうすればいい?
0007デフォルトの名無しさん
2007/10/18(木) 18:54:100008デフォルトの名無しさん
2007/10/18(木) 19:19:53宿題スレにレス来ているよ。
0009デフォルトの名無しさん
2007/10/18(木) 19:46:22つぎに同分野ごとに出現回数からもっとも縮まる単語帳を作る
0010デフォルトの名無しさん
2007/10/19(金) 17:51:19>いちどブロックソーティングするといいとおもう
なぜブロックソーティングするのか理解不能。
何も考えずにmd5でも計算したほうがよっぽど速いだろ。
今使ってる重複検出ツールはまずファイルサイズで確認するよ。
0011デフォルトの名無しさん
2007/10/19(金) 18:11:51例えば、先頭1KだけでCRC計算するより、10Kを1Kに圧縮したものでCRCを計算した方がいいっていう発想
先頭が例えば空白ばかりのファイルが沢山あると区別がつかない
0012デフォルトの名無しさん
2007/10/19(金) 18:47:400013デフォルトの名無しさん
2007/10/20(土) 04:49:48やっぱそのまま64Kとか100Kくらいをハッシュ関数にわたしたほうが良さそうだな
0014デフォルトの名無しさん
2007/10/20(土) 04:58:14ファイルの読み込み、ハッシュの計算、比較の時間
どこにどの位時間をかけるかが重要だ
ファイルを沢山読めば、間違える確率は減るがそれだけ計算時間、読み込み時間がかかる
減らせば一致するファイルが多くなりこちらも比較に時間がかかる
0015デフォルトの名無しさん
2007/10/20(土) 04:59:370016デフォルトの名無しさん
2007/10/20(土) 05:15:170017デフォルトの名無しさん
2007/10/20(土) 05:21:370018デフォルトの名無しさん
2007/10/20(土) 05:33:540019デフォルトの名無しさん
2007/10/20(土) 05:40:34(オープニング/タイトルシーンは同じ場合であることが多いから)
ある程度ファイルのオフセットを取ってから比較すると32Kも比較しなくていい場合もある
ここらへんは、1.まず最初にファイルサイズが一致したら、2.先頭32Kを比較しても一致したら、
3.オフセットを取って比較ぐらいにするといいかも
0020デフォルトの名無しさん
2007/10/20(土) 06:25:37一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする
ファイルサイズと、CRC32を記録しようとすると一ファイルあたり8バイト必要
ファイル数は2^24個なので必要メモリは、最大128MB必要になる
これはスワップアウトを引き起こしてのろくなる原因になりうるが対処法はあるか?
ファイルの読み込みをドライブ別に読み込めば速度が出そう
0021デフォルトの名無しさん
2007/10/20(土) 06:27:070022デフォルトの名無しさん
2007/10/20(土) 06:37:23あと肝心な事を忘れていた ファイル名とそのパスを記録する必要がある ここが一番メモリを消費する
ディレクトリ名は255文字位使えたような気がするのでメモリをくう
ハードディスクの格納方法を知ることが出来れば、文字列を全て記憶する必要はなさそうだが・・・
あとあらかじめサイズなどで比較の必要がないものはCRCの記録までやらなければメモリは減らせるが・・・
しかし、ディスクのシーク時間を考えると、一度ファイル名やサイズを取得したら一緒に32Kくらい読み込んだ方がとくということもある
>>19
ファイルのオフセットとは何でしょうか?
0023デフォルトの名無しさん
2007/10/20(土) 06:41:030024デフォルトの名無しさん
2007/10/20(土) 06:43:43ファイルが登録されている。
最近、複数マシンに渡ってファイルを比較する機能を追加した。
0025デフォルトの名無しさん
2007/10/20(土) 06:44:46・ヒキオタニート
・テラバイト級のストレージを持つ極度のny厨
・秘蔵のロリ画像・動画の収拾がつかなくなったから重複検出をせざるを得なくなった
挙句にム板でオナニースレとかどうしようもないゴミだな。
0026デフォルトの名無しさん
2007/10/20(土) 07:03:04しかし、2^16個以上ある場合は無いだろうから、(a, b, c, ・・・) abcは2バイトの数字でファイルの位置は表せるな
ツリー構造を表現できれば、親ディレクトリの情報は共有できる
>>23
>>19のいうオフセットの比較がわかりません
0027デフォルトの名無しさん
2007/10/20(土) 07:14:28日本で現在最強の検索ツールundupの作者の開発ノートが置いてある
http://hp.vector.co.jp/authors/VA032597/Software/TechNote.txt
ファイルのパスだけど、一階層ずつ32ビット使ったとしてもある程度たまった時点でディスクに保存してしまえばメモリの消費から除外できるな
利用するのは最終的に重複ファイルが決まったときのみだからメモリにおいておく必要なし
0028デフォルトの名無しさん
2007/10/20(土) 07:15:12多分「オフセットを取って比較」ってのは「ファイルの先頭から一定の距離に位置するデータを比較」の意味でしょう。
「ファイルからオフセットを取得して比較」（？）じゃなくて。
0029デフォルトの名無しさん
2007/10/20(土) 07:53:27ディレクトリ構造も保存しておいた方が良いけどコードがが煩雑になる これも入れたやつで速度を測った方が正確か
だれがもっとも速いアルゴリズムが作れるか競おう
CRCの計算方法はここにあるよ
http://laputa.cs.shinshu-u.ac.jp/~yizawa/logic2/chap9/index.html
http://www.geocities.co.jp/SiliconValley/4809/code/index.html
http://www.wdic.org/w/WDIC/CRC
>>28
意味理解しました しかしずらして比較するくらいなら、一度の多くを読み込んだ方がシーク時間が短くなりそう
0030デフォルトの名無しさん
2007/10/20(土) 08:01:29そこのソフトの人の解説流し読みしたけど、かなり幼稚な印象だけど。
自画自賛？というか、もしかして1本人かな・・・
ファイルみたいな総数の判らん対象をオンメモリでソートなんて
やってる時点でソフト寿命はたかが知れてると思うよ。
0031デフォルトの名無しさん
2007/10/20(土) 09:04:07他のソフトと比較した上で言ってるの？
0032デフォルトの名無しさん
2007/10/20(土) 12:53:581,まず他のファイル重複検知ソフト(同業他社)が実装をどのようにしているのかのチェックを>>1はしたの？
2,ブロックソートとか行うと他のソフトとのハッシュ値の互換性がないけどどうするの？
>>1が作成したアプリケーションでしか、ハッシュ値の計算ができなくなるけど…
3,代表的な使用用途・検索するファイルの数/ファイルサイズ・ハッシュ結果のバイト数をできれば教えてください。
0033デフォルトの名無しさん
2007/10/20(土) 13:06:00日本一のファイル比較ツール作者のノートを読みましたよ 他のツールと比較しましたよ
>>32
ブロックソーティングはやめました
ハッシュ地に互換性は入りません そもそもファイル全体のハッシュ値では無い為、他と一致するわけがありません
>>32
条件はこれにしましたよ
同速度のHDD2つ、またはHDDとDVDを検索するとする 一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする
0034デフォルトの名無しさん
2007/10/20(土) 13:06:550035デフォルトの名無しさん
2007/10/20(土) 13:10:56比較した他のツールってどれ？
0036デフォルトの名無しさん
2007/10/20(土) 13:20:15このへん 対抗馬ってなかなか無いよ まともに動作しないのがほとんど ここ一年程度のは調べていないが・・・
http://www.nifty.com/download/cgi-bin/vec_search.cgi?c_set=%83R%81%5B%83h&srch_max=30&key=%8Fd%95%A1&dir_path=%2Fwin%2Futil%2Ffile%2F
http://cowscorpion.com/Software/DuplicateFile.html
0037デフォルトの名無しさん
2007/10/20(土) 14:07:14http://www.vector.co.jp/soft/win95/util/se257049.html
http://lucky.na.coocan.jp/ddchecker.html
0038デフォルトの名無しさん
2007/10/20(土) 14:20:26あとできればまともに動作しなかったのもおながい
0039デフォルトの名無しさん
2007/10/20(土) 15:43:360040デフォルトの名無しさん
2007/10/20(土) 16:03:56レスありがとう。Image Hash Search みたいなものを、作るのかなと思ってたんだけど。
そうではなくローカル環境で動作する重複ファイルの検知ソフトを作るということだよね？
あと>>1で書いている重複という言葉は「バイナリレベルでの完全一致」ということでいいの？
たとえば画像とかの場合はヘッダーだけ違って中身は同じというファイルも多々あるのだけど。
私の質問がわるくてごめん。>>32の3はソフト使用者がどういう用途で、
パソコンを使用しているのかを考慮して、重複検知ソフトを作っているのかという話だったりします。
変な例で悪いけど、P2P使用者とそうでない人ではHDD内にある主なファイル種類・サイズは違います。
よってソフトもそれを考慮して最適化する必要があります。
0041デフォルトの名無しさん
2007/10/20(土) 16:08:26って言葉できるだけつかわずに説明おねがい
0042デフォルトの名無しさん
2007/10/20(土) 16:28:55バイナリの完全一致ですよ ファイルの種類での分類は考慮しない方向でいいと思います
というのも異なる種類なら先頭の方で不一致するからです
>>41
ほとんど ＝ UNDUPや上に上げたソフト以外
0043デフォルトの名無しさん
2007/10/20(土) 16:30:54具体的に
0044デフォルトの名無しさん
2007/10/20(土) 16:32:040045デフォルトの名無しさん
2007/10/20(土) 16:34:460046デフォルトの名無しさん
2007/10/20(土) 16:36:550047デフォルトの名無しさん
2007/10/20(土) 19:26:290048デフォルトの名無しさん
2007/10/20(土) 19:29:413GのMD5を計算するのにどれくらい時間がかかるんだろか? なるべく高速、低メモリが重要
0049デフォルトの名無しさん
2007/10/20(土) 19:31:33既に高速なツールはあるけどもっと高速なのを作りたいの？
0050デフォルトの名無しさん
2007/10/20(土) 19:31:57飽きて放置したまんまだけど。
0051デフォルトの名無しさん
2007/10/20(土) 19:36:410052デフォルトの名無しさん
2007/10/20(土) 19:39:14こういうのって重複したファイルを削除したいってのが目的だから、
サイズの小さいファイル(数百KBの画像とか)をターゲットにしているんじゃないの？
そこらへんが>>1に書いてないからよーわからん。
0053デフォルトの名無しさん
2007/10/20(土) 19:43:15サイズ小さくても、ディスク一杯に詰まっていたら、500G程度読み込んでMD5を計算することになるよ
なるべくディスクの読み込みを減らして比較できた方が良い
0054デフォルトの名無しさん
2007/10/20(土) 19:44:3330秒で思いつかなきゃ素質ないね。
0055NOT 1
2007/10/20(土) 19:58:11いい加減なソフトが多いのは事実だと思うよ。
・なにをもってファイル重複としているのか、マニュアルなどに書いていない。
・NTFSのリパースポイントをソフト側で考慮していない。
すぐにあげれる問題としてはこんなとこ。
0056デフォルトの名無しさん
2007/10/20(土) 22:09:44ファイルは読み込んだ順に連番をつける
ファイル名とその配置、ディレクトリ名はディスクに書き出し、ディレクトリ名とファイル番号とサイズとCRCはメモリに保持する
ディレクトリがあれば最後に進める いくつまで進めたかを記録しておく
調べるディレクトリがなければ上へ戻る
0057デフォルトの名無しさん
2007/10/20(土) 22:11:490058デフォルトの名無しさん
2007/10/20(土) 22:17:140059デフォルトの名無しさん
2007/10/20(土) 22:33:11最初からファイルの先頭読んでく必要ないでしょ。
同一サイズのファイルが出てきた時に初めてやればいい事だし。
つーかアルゴリズムもっと勉強しなさいよ。
辛いんだよこのスレ＞＜
0060デフォルトの名無しさん
2007/10/20(土) 22:38:45>>27をよんで下さい
ディスクのシークにかかる時間を考慮すると、その位置にある時にまとめて同ディレクトリのファイル内容を
取得してしまった方が速いようです
ここです
ソートを行って検索すべきファイルを減らした後で、今まではファイルサイズの順番に従って検索していたのを、
ディレクトリの並び順にCRCを計算していってメモリに記録し、後でファイルサイズ順にCRCを比較していく事にした。
テスト環境では従来の完全比較に比べ半分以下の時間ですみ、簡易検索の後に残った重複している可能性のある
ファイルを完全検索しても充分にお釣りがくる結果となった。
実際にはＭＯの様な極端にシークが遅いのでランダムアクセスが大きな負担にならない様なメディアや、
ほとんどが重複していて簡易検索では候補を絞れないためその後の完全検索で時間がかかり過ぎる場合など、
この新方式では高速化されないケースもある
0061デフォルトの名無しさん
2007/10/20(土) 22:49:23エントリ読みに行ったついでにクラスタサイズ程度読むのは有効かもな。
0062デフォルトの名無しさん
2007/10/20(土) 23:46:130063デフォルトの名無しさん
2007/10/21(日) 00:01:22そこも考えてプログラムもテスト用データも作る必要がありますよ。
0064デフォルトの名無しさん
2007/10/21(日) 00:45:51しばらくしたらアクセス出来る物もあるとは思うが・・・
CRCの計算、ファイルの読み込み、ファイル情報の書き出しを並列化できるとおもう
情報の書き出しはある程度サイズが貯まったらにして、CRCの計算はほとんどかからないだろうから
実質的には読み込み時間だけですむと思う
0065デフォルトの名無しさん
2007/10/21(日) 00:52:561Gのファイルが一致すれば、まともにやると2Gぶん最後まで比較しなければならなくなる
最大、比較サイズを決定してしまうという方法はある たとえば全体の30％ OR 100M 一致すればあとは検査しないとか
あとは、1MずつにCRC計算しておいてデータベースに入れておけば半分ですむ
>>63
テストデータは作るの難しいと思うので直接CやDドライブを実験台にしようと思います
0066デフォルトの名無しさん
2007/10/21(日) 00:54:360067デフォルトの名無しさん
2007/10/21(日) 02:31:25小さいファイルを沢山生成してテストするか こうなると中身を読んだ方が断然いい
0068デフォルトの名無しさん
2007/10/21(日) 03:35:170069デフォルトの名無しさん
2007/10/21(日) 12:52:05http://en.wikipedia.org/wiki/Fdupes
winで動くのもあるね
0070デフォルトの名無しさん
2007/10/21(日) 16:28:37テストデータを生成します 5分ほどかかるかと思います
現在最速ソフト
http://www.vector.co.jp/soft/win95/util/se257049.html
第二位
http://www.vector.co.jp/soft/win95/util/se257656.html
0071デフォルトの名無しさん
2007/10/22(月) 14:17:25それとも書き込む順番どおりなの?
0072デフォルトの名無しさん
2007/10/22(月) 14:29:260073デフォルトの名無しさん
2007/10/22(月) 14:40:48ここらへんにかいてあるが不明
0074デフォルトの名無しさん
2007/10/22(月) 14:52:130075デフォルトの名無しさん
2007/10/23(火) 02:26:19m ディレクトリの階層の深さ
n 見つかったファイル総数
M 最大階層数
N 最大ファイル総数
dirname(i) 各階層のディレトリ名
dirban(i) 何番目に上のディレクトリが見つかるか
file(k) 現在調べているディレクトリでのファイル情報( 名前、サイズなと゛)
filesyori () {
path = dirname(0) +・・・+dirname(m)を開く
k=0;
if ( file(k)がファイル)
0076デフォルトの名無しさん
2008/01/14(月) 22:01:090077デフォルトの名無しさん
2008/01/18(金) 22:01:300078デフォルトの名無しさん
2008/01/18(金) 22:09:300079デフォルトの名無しさん
2008/04/19(土) 04:05:56UnDup にデータベース機能がついた様なソフトが
理想形となってるみたいですね。デスカ？
0080デフォルトの名無しさん
2008/04/19(土) 17:26:50同サイズのファイルが大量にあると若干遅くなるけど
0081デフォルトの名無しさん
2008/04/19(土) 17:36:38それ考えたけど、データベース作成後に
ファイルが更新されているかどうかを調べるのが困難。
HDDだと書き換えられるから、全体を再チェックしなくてはいけなくなる。
それにデータベース作成時間程度かかる気がする。
008281
2008/04/19(土) 17:40:24しかし、重複であるものを、重複とみなさないケースが出てきてこれを見つけるのが困難になる。
結局、全部検索することになりそう。
0083デフォルトの名無しさん
2008/04/19(土) 17:46:22重複検出を一回やるだけなら全部オンメモリで処理しても足りると思うんだけど。
後で別の重複検出をやるときにDBに入れたデータを再利用するってことなのかな？
そうそう再利用できるケースがあるとも思えないけど…そんな同じファイルを何回もHDD上に生成したりするものだろうか？
ファイルのハッシュ値と詳細を記録するとかだったらまだわかるんだが。
0084デフォルトの名無しさん
2008/04/19(土) 17:47:410085デフォルトの名無しさん
2008/04/19(土) 17:50:14おもな利用方法はCD、DVDとの比較と思います。データベース導入ならHDDもしないと不自然だなと思うわけです。
0086デフォルトの名無しさん
2008/05/03(土) 08:42:33500円として100個は売れますか?
0087デフォルトの名無しさん
2008/05/03(土) 08:48:340088デフォルトの名無しさん
2008/05/03(土) 09:01:50あとデータベース機能機能もつけて、UNDUPの速度を半分以下にしたら幾らくらいですか?
0089デフォルトの名無しさん
2008/05/03(土) 09:07:28500円でも1000円でも売り上げ本数は変わらんだろう。売れるかどうかは別問題だが。
0090デフォルトの名無しさん
2008/05/03(土) 09:24:440091デフォルトの名無しさん
2008/05/03(土) 09:30:020092デフォルトの名無しさん
2008/05/03(土) 11:35:230093デフォルトの名無しさん
2008/05/03(土) 14:35:46どうでもいいのに金払うのが面倒だろ
0094デフォルトの名無しさん
2008/05/03(土) 17:50:17わざわざ得体の知れないシェアを使おうとは思わないな。
それに使うとしても月に一回ぐらいだろ?
0095デフォルトの名無しさん
2008/05/03(土) 18:49:16思ったんです。大して売れなくても良いんですけど、
UNDUPを完全に上回ったとしたらどの位かなとおもったんです。
0096デフォルトの名無しさん
2008/05/03(土) 23:30:51UNDUPがあるんだし、他の、しかもシェアウェアを
わざわざ選ぶ理由なんてあるか？ゼロだろ。
買われるとしたら、検索もできないネット覚えたての
情報弱者がたまたま最初にみつけて、間違えて買うぐらいだな。
今時小学生でもありえないが。
UNDUP程度なら誰でも作れるんだし、ここでぐだぐだ
売れるかどうか、なんて書いてる奴のソフト、しかも
猿真似のシェアウェアが売れると思うか？
この程度のソフトなんて作っても金にならんぞ。
オクで転売でも始めた方が儲かるんじゃないか？
0097デフォルトの名無しさん
2008/05/04(日) 11:28:300098デフォルトの名無しさん
2008/05/04(日) 17:29:09全ファイルのMD5とかSHAハッシュ取ってsortコマンド使えばええやん
殆ど重複はしないでしょ
でかいファイルは4MBくらいで読むの止めて、サイズ一緒に出力しておけばいいし
0099デフォルトの名無しさん
2008/05/04(日) 19:56:15小学生は大人になってから来てね
0100デフォルトの名無しさん
2008/05/20(火) 00:25:58ttp://www.vector.co.jp/soft/win95/util/se373076.html
0101デフォルトの名無しさん
2008/05/25(日) 22:20:27画像MD5比較で条件付削除ができるようにして
0102デフォルトの名無しさん
2008/05/25(日) 23:09:45どんな面しているんだか。
0103デフォルトの名無しさん
2008/05/26(月) 00:01:490104デフォルトの名無しさん
2008/05/28(水) 09:02:170105デフォルトの名無しさん
2008/07/19(土) 12:49:02find /hoge -type f | xargs cksum | perl ckchk.pl | sh
#!/usr/bin/perl
while(<>) {
chomp;
if (m/^(\d+ \d+) (\S+)$/) {
if (defined($filename{$1})) {
printf("diff -q '%s\' '%s\' && rm '%s\'\n", $filename{$1}, $2, $2);
next;
}
else {
$filename{$1} = $2;
}
}
}
0106デフォルトの名無しさん
2008/08/18(月) 19:07:300107デフォルトの名無しさん
2008/08/22(金) 06:34:19Win32API使ってる時点でこれが限界か
しかし>>1の着眼点面白すぎだな
2^24個のファイルってMFTが16Gになるぞ
その上ファイルサイズは4G制限かｗ
てかたった1年前の話なのにCRC16とか出ててフイタｗ
5年位前のカキコかと思ったわ
0108デフォルトの名無しさん
2009/01/06(火) 09:05:410109デフォルトの名無しさん
2009/01/06(火) 15:18:16大方>>1の見え透いた用途では、古いファイルが変更される事は
少ないんじゃないか？だったら
キャッシュ.txt:
最終更新年月日
MD5等ハッシュ ファイルパス
MD5等ハッシュ ファイルパス
MD5等ハッシュ ファイルパス
・
・
・
とファイルをフォルダごとに作っておいて、比較対象は最終更新年月日より
タイムスタンプが新しいものに限ると。これだけで>>1の様な用途なら十分
高速に使えると思うぞ。
0110デフォルトの名無しさん
2009/01/06(火) 16:56:490111デフォルトの名無しさん
2009/01/07(水) 01:56:44これはどう？
0112デフォルトの名無しさん
2009/01/10(土) 03:04:16でもかぶってるファイルが多数あるのでそれらをまとめてから焼きたいのですが
どうすればいいですか？
0113デフォルトの名無しさん
2009/01/10(土) 03:16:160114デフォルトの名無しさん
2009/01/10(土) 23:24:31ファイルの重複検出ツールのスレですよね？
0115デフォルトの名無しさん
2009/01/10(土) 23:33:18で、お前はどういう方針でツールを作ろうとしてるの？
0116デフォルトの名無しさん
2009/01/11(日) 01:31:35ファイルコピー→＜ファイルチェックプロセス＞→ディスク
って感じで。
ファイルサイズとかハッシュが同じファイルを通そうとしたら弾くとか。
0117デフォルトの名無しさん
2009/01/11(日) 04:22:32馬鹿発見
0118デフォルトの名無しさん
2009/01/11(日) 11:05:58重複検出ツールを「作ろう」ってスレだろ、ＪＫ
0119デフォルトの名無しさん
2009/01/12(月) 10:11:42その成果だけ頂きたいのです、女子高
0120デフォルトの名無しさん
2009/01/12(月) 10:53:45http://pc11.2ch.net/test/read.cgi/software/1145546190/
0121デフォルトの名無しさん
2009/01/13(火) 15:44:22未成熟ぎみなのがいいんです、JC
0122デフォルトの名無しさん
2009/01/14(水) 13:42:17方法はないでしょか？
完全一致のファイルならファイル名と MD5 のデータベースを作っておけばファイル数に
関係ない時間で検索できるのですが。
0123デフォルトの名無しさん
2009/01/14(水) 14:25:20ある通信プロトコルでの相手を決定するための方法だけど、
その数十万個分のファイルに対応するオブジェクトを作る。
指定のファイルのオブジェクトのビット(特徴)を、1こずつそれらに送る。
同じビット(特徴が一致した)なら応答を返す。
応答が最も多かったファイルを「ほぼ同じ内容」と判断する。
ようするに、比較をインクリメンタルにやるという話。
ハードウェアでの通信だと一瞬で判定できる。
それをソフトウェアでやると個数分の時間が掛かる。
まあ総当りするよりは速い。
0124デフォルトの名無しさん
2009/01/14(水) 14:31:22あとは人間が確認する。
0125デフォルトの名無しさん
2009/01/14(水) 14:35:590126デフォルトの名無しさん
2009/01/14(水) 14:39:270127デフォルトの名無しさん
2009/01/14(水) 17:40:080128デフォルトの名無しさん
2009/01/14(水) 22:02:320129デフォルトの名無しさん
2009/01/14(水) 22:04:270130122
2009/01/15(木) 14:04:06現在使っている MD5 以外の検索方法は
ベースファイル名が一致しファイルサイズが近いものを DB から抽出し、
ファイルの最初の 128KB のバイナリ差分が小さいものに絞り込み、最後に
ファイル全体のバイナリ差分が小さいもの選んでいます。
この方法でそこそこの時間で検索できますが、大幅な絞り込みのために
ファイル名を使っているのでファイル名が全然違うファイルは検索対象に
ならないので困っています。
0131デフォルトの名無しさん
2009/01/15(木) 14:27:57のMD5を保持しておけよ。
0132デフォルトの名無しさん
2009/01/15(木) 14:48:450133デフォルトの名無しさん
2009/01/15(木) 15:00:17でぐぐれ
0134デフォルトの名無しさん
2009/01/15(木) 15:09:56ソースコードならクラス、メソッド名だけ抽出して比較すりゃ終わりじゃね？
もっと確度上げたいなら変数名も追加
0135デフォルトの名無しさん
2009/01/15(木) 15:24:000136デフォルトの名無しさん
2009/01/15(木) 19:07:030137デフォルトの名無しさん
2009/01/15(木) 19:12:13お前の恥ずかしさに免じて何も指摘しないでやる
0138デフォルトの名無しさん
2009/01/15(木) 19:27:30大きく代わることがあるだろ。
0139デフォルトの名無しさん
2009/01/15(木) 19:28:190140デフォルトの名無しさん
2009/01/15(木) 19:35:05お前なぁ、自分で墓穴掘ってちゃ世話無いだろうが
もう分かったから、そのまま墓穴に埋まっててくれ
0141デフォルトの名無しさん
2009/01/16(金) 12:21:290142デフォルトの名無しさん
2009/01/16(金) 12:27:170143デフォルトの名無しさん
2009/01/18(日) 07:35:52ソースコードだったら大体同じようなクラス名や関数名で書いてるだろ
分かりにくいコード書いてるやつがいたら穴掘って埋めればおｋ
0144デフォルトの名無しさん
2009/01/19(月) 10:40:44どなたかご存じないですか？
0145デフォルトの名無しさん
2009/01/19(月) 11:21:29http://pc11.2ch.net/test/read.cgi/software/1145546190/
0146デフォルトの名無しさん
2009/06/03(水) 15:53:24・ファイルリスト出力ツール＝フォルダ内のファイルをリスト化。テキストにMD5付きで出力(ファイル名、ファイルサイズ、MD5) DVDに焼く前の汎用ファイルリストとしても使えるかな。
・チェックツール 上記ツールで作ったテキストをDBとして、フォルダ内のファイルを順にMD5出して、もしDB内にあるファイルがあれば自動削除
これで一旦リスト化すれば、ファイルはDVDとかに移動しても、リストだけで比較・重複ファイル削除できるからパソコンに同じファイルがある必要もない。
重複チェックツールは数あれど、DB化したファイルから検索するのは少ないし、ややこしい操作多いし、自分でつくりました。
速度はHDDのリード速度に比例する。毎秒100MB/sくらいかな。1GB10秒 60GBのフォルダなら10分＜＜ファイル全体のチェックのシステム上、これ以上は速くならないから勘弁。
0147デフォルトの名無しさん
2009/06/03(水) 20:22:12先頭5K、10Kも比較すればほぼ判定できる。
すべてのデータのハッシュを計算するのはよくあるが鈍すぎる。
5Kで異なればすでに異なることが判定できている。
0148デフォルトの名無しさん
2009/06/04(木) 11:04:27独自解析形式にしたら、そもそも汎用性がなくなる
既存のツールのMD5表示と同じものがリスト化されるのが有意義なのに。
速度も最近のHDDなら結構はやい。25GBでリスト化2分程度。
そもそも、これはDVDとかに焼いてもうパソコンに無いファイルとの比較を誤差なく重複検知する
のが主眼なので、一旦リスト化されたものを検索するだけだから、リスト化さえすれば非常に高速。<<テキスト見てるだけなので
最近追加されたファイルだけをMD5するだけだから、時間はそんなにかからん。
あとあとのことを考えれば独自形式にするほうがめんどい。
0149デフォルトの名無しさん
2009/06/04(木) 11:08:040150デフォルトの名無しさん
2009/06/04(木) 11:11:36公称1GB/sの超高速PCIe-SSDが発売
http://www.watch.impress.co.jp/akiba/hotline/20090530/etc_pfast2.html
こんなのも出てるから、新規追加分だけMD5化する時間なんて誤差の範疇。
こういうのが一般化する将来のことも考えて、汎用MD5値をリスト化するほうがいい。
あとあとこの先何年も自分が使うリストだからな。
0151デフォルトの名無しさん
2009/06/04(木) 11:27:05クラッキングとかじゃなしに、普通のファイル検索でMD5一致って何分の1の確率ですか？
そんなに頻繁に衝突するようなら、ファイルサイズとMD5が完全一致した場合のみ重複と判定
ともできますが、ファイルのMD5はよく一致するものでしょうか？
16^32＝の確率でたしかに偶然に一致しますが、ちょっと天文学的な確率なので。(1/3.40282E+38 分の1の確率？)
0152デフォルトの名無しさん
2009/06/04(木) 11:32:49あと、いかに早く検索できるかが大事
60GHDDのサーチに10分もかかるのはだめだね
0153デフォルトの名無しさん
2009/06/04(木) 11:37:15テキストファイルで、後半だけ変更したりすると検出できない確率はあるが。
そういうやつは特別に扱って別の位置も取得しておけばいい。
0154デフォルトの名無しさん
2009/06/04(木) 12:15:050155デフォルトの名無しさん
2009/06/04(木) 12:19:29さらにチェック
とすれば、数百倍の速度になると思います。怪しいものだけチェックすれば、それ以外はMD5チェックいらないし。
ファイルサイズ違えば違うファイルだし。「類似」がどうのは自分には難しいので自分はパスします。
0156デフォルトの名無しさん
2009/06/04(木) 21:03:31UNDUPしかない感じだからいいやつ頼む。
0157デフォルトの名無しさん
2009/06/05(金) 15:15:21確率はかなり低いだろうが、鈍いことが問題。
1000万ファイルもあれば一つくらいは衝突するのでは
0158デフォルトの名無しさん
2009/06/05(金) 17:37:293百澗分の1。 1000万ファイルすでにもってても、それに一致は百穣分の1
ゼロではないが、気にしてもしょうがねー数字。というか何分の1かぴんとこないな。
http://ja.wikipedia.org/wiki/%E4%B8%87%E9%80%B2#.E5.A4.A7.E6.95.B0
あと高速化も兼ねてるファイルサイズ一致兼、MD5一致なら、これよりさらに100万分の1とかの確率
0159デフォルトの名無しさん
2009/06/05(金) 17:52:00初心者乙。
もっともいい分布でハッシュが作れたとしても、そんなに低くない。
たとえば、5個のうち3つ選んで重複しない確率は、1/5ではない。
1/2^128 というのは、2つだけハッシュを生成して衝突しない確率。
1000万個すでにハッシュが生成していたらそれにかぶらない数字でなければいけない。
0160デフォルトの名無しさん
2009/06/05(金) 18:00:29p(1)=1/K
p(2)=p(1) + (1 - p(1)) * 2/K
・・・
一般に
p(n+1) = p(n) + (1 - p(n)) * (n+1)/K
という式で表される確率だろう。
解き方はしらんが。
0161デフォルトの名無しさん
2009/06/05(金) 18:01:54だから1000万ハッシュがある場合は、10^7減って 1/3.40282E+31 3百穣分の1になるんだろ。
たしかに3百澗分の1より3百穣分の1のほうが数字的にはかなり確率が高くなるが、
そんな単位にそもそも何の意味があるのか理解できません。
「百穣分の1なんて多すぎる！」と気にする人はMD5一致兼、SHA1一致兼、SHA256兼、SHA512一致の多重チェックで
好きなだけ確率を追い求めればいいと思います。
0162デフォルトの名無しさん
2009/06/05(金) 18:05:09雑多な階層のZIPファイルの重複検知がてこずってましたが
＞＞サイズが中間フォルダのせいでか、微妙に違い
MD5も違ってくるから、「違うファイル」とされる。(同じ画像フォルダなのに)
これをなんとかするには、「解凍+後始末α」とかでZIPファイルを解凍しつつ
一層化して、再度無圧縮ZIPにする
これでMD5が完全一致するから、重複削除可能。
(名前によらずMD5値だけで削除できる)
無駄なテキストや、htmlの削除で無圧縮ZIP化する前に不要ファイルを削除して共通化も必要
これにはFcleanが便利。
0163デフォルトの名無しさん
2009/06/05(金) 18:05:12初心者乙。 1000万個目までに一回でも衝突が起こっていたらだめ。
うまく1000万個目が衝突しなくても、それまでに衝突が起こっている事はある。
0164デフォルトの名無しさん
2009/06/05(金) 18:07:04ファイルの中身のデータを取得して比較しよう。
サイズや日時や名前が使える。CRCもあったような気はする。
0165デフォルトの名無しさん
2009/06/05(金) 19:06:35だから1000万で割ればいいだけでしょ。分子が1000万なら分母も1000万10^7で割ればいいだけ。
1/3.40282E+31 3百穣分の1 単純な計算です。
というか、UnDupはCRC32で16の8乗 たった4億分の1 自分のはMD5 16の32乗
全然いいと思いますが。SHA1にもできますが、MD5で十分だと思うので。
サイズ一致とMD5一致の多重ならMD5より数万倍上だし。
それでも不満なら、SHA1とMD5を両方完全一致やるというのも可能ですが、
2倍以上時間かかるし、効果もよく分からんので。 どうしてもやれといわれれば、作りますが。
0166デフォルトの名無しさん
2009/06/05(金) 20:29:59初心者は無視した方がいいのかな・・・
0167デフォルトの名無しさん
2009/06/05(金) 20:33:460168デフォルトの名無しさん
2009/06/05(金) 22:24:56サイコロ 6面
1が出る確率＝1/6
2が出る確率＝1/6
1か2が出る確率＝1/6+1/6＝2/6=1/3
1か2か3が出る確率＝1/6+1/6+1/6＝3/6=1/2
3.40E+38面のサイコロと考えればいい(1つの値が出る確率は常に1/3.4E38で一定)
3.40E38＝Xとする
1が出る確率＝1/X 2が出る確率＝2/X 1か2か3が出る確率＝3/X
１〜1000万の数値のうち、どれかが出る確率 1000万/X
1000万個登録してあって、さらに1000万個検索する場合 2000万/X
すでに1.7E+38=170澗個のファイルが登録してあれば、1.7E+38/3.4E38=2分の1の確率です。
0169デフォルトの名無しさん
2009/06/05(金) 22:43:42逆に出ない確率は サイコロの数値を順に登録していく場合
最初＝1(100%でない) 1が出た＝5/6 2が出た4/6 3が出た3/6
5/6x5/6x5/6=25/216
1回目＝まだ1つもないから1
2回目＝1つあるから、それ以外(3.4E+38-1)/3.4E+38
3回目＝2つあるから、それ以外(3.4E+38-2)/3.4E+38
1,2,3回とも1つも重複しない確率＝1x(3.4E+38-1)/3.4E+38x(3.4E+38-2)/3.4E+38
N回やって、1つも重複しない確率＝1x
1〜1000万回やって、1つも重複しない確率＝
1x(3.4E38-1)(3.4E38-2)
-----------------------〜 ＝ 3.4E+38^N
1x 3.4E+38 x3.4E+38〜
ややこしいので、近似します。最悪になっている
1000万個すでに登録してある場合
=(3.4E+38-10000000)/3.4E+38 ですので、これを1000万回乗数でかけます。
={(3.4E+38-10000000)/3.4E+38}^10000000
1〜1000万回やって、1つも重複しない確率＝
エクセルで=100*((3.4E+38-10000000)/3.4E+38)^10000000 の数値を入れてみてください
それが1000万回MD5をリストに登録しつづけて、1つも重複しないパーセンテージでの確率です。
0170デフォルトの名無しさん
2009/06/05(金) 22:46:24MD5のハッシュが一致しないって言うのは、999万9999個目まで一度も一致しない確率が必要。
さいころでたとえれば、
さいころを2回振って重複する確率 = 1/6 = 0.166
さいころを3回振って重複する確率 = 2回目までに重複する確率 + 2回目までに重複しない確率 * 2/6 = 0.444
さいころを4回振って重複する確率 = 3回目までに重複する確率 + 3回目までに重複しない確率 * 3/6 = 0.722
さいころを5回振って重複する確率 = 4回目までに重複する確率 + 4回目までに重複しない確率 * 4/6 = 0.907
0171デフォルトの名無しさん
2009/06/05(金) 22:53:38たとえば
さいころを5回振って一致しない確率 = 6*5*4*3*2 / 6^5 = 0.9074
0172デフォルトの名無しさん
2009/06/05(金) 22:58:56MD5が一度も一致しない確率は、 N(N-1)・・・(N-M+1)/N^M だな。
0173デフォルトの名無しさん
2009/06/05(金) 23:20:260174デフォルトの名無しさん
2009/06/07(日) 00:05:14sha1 434783/s 1096% 278% 263% 121% 26% 24% -- -50% -64%
ds_sha1 869565/s 2291% 657% 626% 342% 151% 148% 100% -- -28%
md5 1204819/s
SHA1以上にするととろいんですよ。
0175デフォルトの名無しさん
2009/06/07(日) 01:26:46全部生成したら、主にディスクアクセス速度に依存する。
0176デフォルトの名無しさん
2009/06/07(日) 01:29:32ハッシュの分布頻度を均一にしようとしていないだろ。
ビットあたりの無駄のなさをはかればCRCが飛び抜けてるんでは。
CRCは32が有名だが、64でも128でも出来る。
0177デフォルトの名無しさん
2009/06/07(日) 01:32:19＞ハッシュの分布頻度を均一にしようとしていないだろ。
初耳、ソースplz
0178デフォルトの名無しさん
2009/06/07(日) 01:40:58CRCは誤り検出符号の一種である。
CRCがよく使われている重要な理由として、効率が保証されている点が挙げられる。
nビットCRCは、nビット未満のバースト誤りを検出できる。
また、それより長いバースト誤りも 1-2-n の確率で検出する。
データ通信での誤りも記憶装置での誤りも、誤りは無作為に出現するわけではなくバースト性がある。
そのため、CRCの性質はそれらによく合っている。
CRCとセキュリティ
CRC の数学的特性上、CRC値が変化しないように元のデータを改ざんすることが容易であり、
CRC単独では意図的なデータ改ざんを検出するのには向いていない。
CRCはデータ完全性のチェックに使われるが、それと暗号化とは別である。
巡回冗長検査 - Wikipedia
http://ja.wikipedia.org/wiki/%E5%B7%A1%E5%9B%9E%E5%86%97%E9%95%B7%E6%A4%9C%E6%9F%BB
0179デフォルトの名無しさん
2009/06/07(日) 01:57:420180デフォルトの名無しさん
2009/06/07(日) 03:01:50SHA1は10MBのファイルでQ6600で60sかかるから無理ぽ。
1000Mのファイル1個のSHA1値出すのにまるまる100分間？
強度がどうこう以前に選択肢にもならん。
0181デフォルトの名無しさん
2009/06/07(日) 04:05:34SHA1は10MBが1秒以内
0182デフォルトの名無しさん
2009/06/07(日) 04:09:19これも一秒以内
10Mでは比較が出来ん
0183デフォルトの名無しさん
2009/06/07(日) 04:14:55ディスクをいいタイミングで読み込めたかどうかだけと思う。=ディスクアクセスの差と思う。
0184デフォルトの名無しさん
2009/06/07(日) 05:22:1724.6GBのファイル(動画)で時間みたら
MD5が4分13秒 253秒
SHA1が3分50秒 230秒だった。
ほぼHDDのリード速度かな。
重複検知つくってるやつですが、
MD5でもSHA1でもSHA256でもSHA512でもできますね。
SHA256、SHA512はあまり速くない。モジュールが悪いせいか。
10MBでSHA256 34秒 SHA512 26秒
まあ暇な人はSHA512版も使えるようにします。SHA512だと1.34E154通りですか。何分の1ですかね。
0185デフォルトの名無しさん
2009/06/07(日) 11:11:19http://www.volny.cz/lk77/crc256mmx/index.htm
0186デフォルトの名無しさん
2009/06/07(日) 11:16:201993年にはじめに発表されたものは、公式にはSHAと呼ばれている。
しかしその後のものと区別するためにしばしばSHA-0と呼ばれている。
2年後、SHAに初めての後継となるSHA-1が発表された。
さらにSHA-224、SHA-256、SHA-384、SHA-512と４つの変形が、
増加する出力の範囲とわずかなデザインの違いで発行されている。
それらはしばしばまとめてSHA-2といわれている。
SHA - Wikipedia
http://ja.wikipedia.org/wiki/SHA
0187デフォルトの名無しさん
2009/06/07(日) 11:17:150188デフォルトの名無しさん
2009/06/07(日) 11:21:15たとえば、32bit取り出してみて、CRCと衝突回数比較してみるなど。
0189デフォルトの名無しさん
2009/06/07(日) 11:26:59違うって言うならその根拠を示してみろ
0190デフォルトの名無しさん
2009/06/07(日) 11:27:23もともとが暗号の為のもの。wikipediaでもみろよ。
ハッシュの散らばり具合は、ある程度はいいだろうけど、
同一ハッシュが生成されないようにすることの方が大事。
0191デフォルトの名無しさん
2009/06/07(日) 11:29:38実験してみればわかる。
いまの場合だと、同一ハッシュが求めらない耐久さより、
衝突が起こりにくいことが大事。
0192デフォルトの名無しさん
2009/06/07(日) 11:35:11たとえば、x[n]は4バイトの配列として、
x[0]+x[1]+x[2]+・・・や、x[0] xor x[1] xor x[2] xor ・・・や、
x[0]+x[1]+x[2]+x[3]でもいい。衝突が起こらないければいい。
0193デフォルトの名無しさん
2009/06/07(日) 12:15:25そのWikipediaにハッシュ関数とはハッシュに値上の偏りが無いことが要件の一つって書いてあるけど
>>176の２行目はそれを否定してる、その理由を訊いてるんだけど？
0194デフォルトの名無しさん
2009/06/07(日) 12:34:29偏りが出ないことだけを追求したハッシュの違い。
0195デフォルトの名無しさん
2009/06/07(日) 12:48:12偏りがでなければそれはすなわち暗号ハッシュに使えるのでは？
偏りがあったら、暗号ハッシュとして攻撃されやすく脆弱性がある欠陥品だろ。
0196デフォルトの名無しさん
2009/06/07(日) 13:41:12CRCに比べればって話か
なら分布頻度を均一しようとしていないってのは言いすぎだろ
0197デフォルトの名無しさん
2009/06/07(日) 13:57:12(暗号も通常も) ハッシュとして衝突が起こりにくいことはまず必要。
あるハッシュ道が与えられたとき、
計算で一致するデータが求められるかは、上の衝突とはあまり関係がない。
0198デフォルトの名無しさん
2009/06/07(日) 14:01:070から255が一回ずつ現れれば、衝突は一度も起こらない。
しかし、ハッシュ値 1と一致するするデータほ生成することは容易。
257 & 255 = 1
0199デフォルトの名無しさん
2009/06/07(日) 14:03:17そもそも「暗号ハッシュ」という括りが一般には存在しないのでは？
ハッシュ（切り刻む・滅茶苦茶にする）は、大きなデータから
一方向性と非衝突性を"なるべく"満たすような小さなデータを
作り出す操作を指す。
確かに、その主なアプリケーションは、デジタル署名や共通鍵(TKIP)
の生成だが、それはハッシュ値が
・元データが違えばだいたい違う値になる
・ハッシュ値から元データを類推するのが難しい
という性質を利用した物で、そのためにハッシュがあるわけではない。
ファイルが、"多分同じ"で有ることを確認するためにも使われるし、
大きなデータを扱って、100.00% が求められない データベースの
インデックスとしても使われる。
0200デフォルトの名無しさん
2009/06/07(日) 14:16:52MD5、およびRIPEMDとよばれるハッシュ関数には理論的な弱点が存在することが明らかとなっている。
2004年8月、暗号の国際会議 CRYPTOにて、
MD5のコリジョンを求めることができたという報告があった。
また2007年11月、2つの全く異なる実行ファイルを元に、各々の末尾にデータブロックを付加し、
その部分を変更しながら探索を行うことにより、同一のMD5を持たせることに成功したという報告があった。
この攻撃方法は実証されたことになる。
2007年4月IPAはAPOPの脆弱性について警告した。
これは電気通信大学の太田和夫教授（暗号理論）の研究グループが発見したもので、
MD5ハッシュから理論的に元のパスワードを求めることが出来たというものである。
この対策としてMD5を用いるAPOPではなくSSLの利用を推奨している。
ハッシュの衝突耐性について
MD5のハッシュ値については、パソコンレベルで、数10分程度で、
同一ハッシュ値の非ユニークなデータ列を生成できる実装が広まっている。
すなわち、強衝突耐性は容易に突破されうる状態にある
SHA-0/SHA-1アルゴリズムについても、MD5ほど容易ではないが突破される脆弱性が発見されている。
MD5 - Wikipedia より
0201デフォルトの名無しさん
2009/06/07(日) 14:19:40SHA-3（Secure Hash Algorithm 3）は、NISTが公募中の新しいハッシュ関数アルゴリズムである。
現在は公募されたハッシュ関数が公開され、これから評価を行うフェイズにある。
ハッシュ関数としてはSHA-1が米国標準となっていたが、ハッシュ関数攻撃手法の発展とともに、
SHA-1の衝突発見の可能性が現実的なものとなったため、NISTはSHA-1に替わるハッシュ関数の公募を行うことを決定した。
SHA-1のブロック長は160ビットであるが、誕生日攻撃に必要な計算量をAESの全数探索計算量と同じくするため、
ブロック長は256ビット以上となると考えられる。
0202デフォルトの名無しさん
2009/06/07(日) 14:25:18それは強衝突耐性の話
0203デフォルトの名無しさん
2009/06/07(日) 14:27:24重複検知は、理論上、誤検知確率が潔癖症が好きな「ゼロ」にはなりえないから
そんなに病的に気にするやつは重複検知なんかするな、全部まとめて保存しろ。
それなら間違って削除することもないだろうよ。
0204デフォルトの名無しさん
2009/06/07(日) 14:42:11128bit中、上位120bitが常に0だったりすれば、暗号強度も弱いし、衝突も起こりやすいが
そういう間抜けな関数でない限り、
暗号強度が高くても、衝突は起こるし
逆に衝突が起こらなくても、暗号強度は低いことはある。
0205デフォルトの名無しさん
2009/06/07(日) 14:42:54http://ja.wikipedia.org/wiki/%E5%B7%A8%E5%A4%A7%E6%95%B0
宇宙の原子の数は10^81個 SHA512は10^154
Googleという名前が、実はとある数字と関係するって知ってました？ ＝グーゴル - 10^100
0206デフォルトの名無しさん
2009/06/07(日) 14:45:081億の内容の異なるファイルの中に同値のハッシュが存在する確率は
0.00000000000000000000147パーぐらい(多分)
0207デフォルトの名無しさん
2009/06/07(日) 14:46:45勝手に変な結論をださないでくれ。
>暗号強度が高くても、衝突は起こるし
暗号強度が高ければ衝突は起こりにくい。
暗号強度が低ければ衝突が起こりやすい。
例外はない。 わけのわからない結論を出さないでくれ。
0208デフォルトの名無しさん
2009/06/07(日) 14:53:21こういうのを見るとブロック化は問題ですね。やっぱファイル全体のMD5で検知しないと。
0209デフォルトの名無しさん
2009/06/07(日) 14:54:22分布はなかなか良い。(衝突は起こりにくい)
0210デフォルトの名無しさん
2009/06/07(日) 15:02:26たとえば、x%100 という関数と暗号強度は変わりはない。
この場合、ハッシュ値10と一致するのは、100n + 10 と一般項が求められる。
0211デフォルトの名無しさん
2009/06/07(日) 16:17:18暗号の話じゃなくて、ツールの話でしょ。
0212デフォルトの名無しさん
2009/06/07(日) 19:32:250213デフォルトの名無しさん
2009/06/07(日) 19:54:44「重複確認」が便利だな。
これにDVDとかにあるファイルのMD5も参考に削除できればいいのに。
0214デフォルトの名無しさん
2009/06/07(日) 19:57:30だが「重複確認」とFastHashの両方の機能を合わせたのがない。
0215デフォルトの名無しさん
2009/06/07(日) 20:05:26削除もできるね。比較モード
これでいいかもな。このスレ終了？
0216デフォルトの名無しさん
2009/06/08(月) 00:47:33どういうアルゴリズムなのかは知らないが。
0217デフォルトの名無しさん
2009/06/09(火) 11:30:370218デフォルトの名無しさん
2009/06/10(水) 22:19:46こんだけのことが結構難しくて苦慮中・・・
0219デフォルトの名無しさん
2009/06/10(水) 23:29:210220デフォルトの名無しさん
2009/06/11(木) 03:23:19＝怪しいものだけをさらにMD5チェックかけるんだな。
ファイルサイズも同じで、MD5でも同じなら天文学的確率でファイルが同じなので削除と。
0221デフォルトの名無しさん
2009/06/11(木) 11:57:360222デフォルトの名無しさん
2009/06/11(木) 19:12:33高速化できてかつ、通常のMD5の1億倍以上の精度にはなったはず。一石二鳥？
次は既存リストとの照合か。
0223デフォルトの名無しさん
2009/06/11(木) 19:21:210224デフォルトの名無しさん
2009/06/11(木) 20:03:35どうせハッシュ(間違いはある)
前後と真ん中の3カ所くらいだけ抜き取れば十分
4GのISOとか読み込みのはだめだろ
0225デフォルトの名無しさん
2009/06/11(木) 20:10:03MD5ではまれに間違える。
重複候補をリストアップして、あとは手動か、完全比較を選ばせばいい。
全ハッシュでは、4G以上のファイルがあれば、いくら高速化しても無駄になる。
0226デフォルトの名無しさん
2009/06/13(土) 20:10:58肝心の速度だが、
ファイル数10508 総容量265GBのフォルダの重複一括削除で
MD5版
4分19秒
SHA1版
8分47秒
リスト内検知も高速で、サイズ一致がない場合(MD5検査に入らない場合)
ファイル数10508検査が2秒で完了 基本的にサイズが一致しない限り、MD5検査とかしないからかなり高速。
リスト内のサイズと一致した場合 MD5する必要があるが、これはHDD読み出し速度程度の所要時間。
↑の場合以上にかかることはほぼないはず。(このフォルダ例は相当の重複(1割以上)が多数フォルダにあるやつなので)
こんなもんでいいですか？ HPでアップします。
0227デフォルトの名無しさん
2009/06/13(土) 22:19:280228デフォルトの名無しさん
2009/06/14(日) 03:12:51こんな感じで。一応変な挙動がないか確認しましたが、
やばい問題がありましたら、再現状況を添えてメールしてください。
汚いソースですいません。
0229デフォルトの名無しさん
2009/06/14(日) 14:53:54まだ実際に試してないんだけど、これって最初に全ファイルのハッシュリストを作成するの？
もしそうなら、比較するときもリスト内のハッシュ同士の比較で良くない？
0230デフォルトの名無しさん
2009/06/14(日) 15:11:460231デフォルトの名無しさん
2009/06/14(日) 17:54:31DVD等に焼くファイルのリスト化は、最大限の情報抽出が必要なので
全ファイルのMD5値を出します。
手元にあるファイルのフォルダ内重複確認・リストと照らし合わせての重複確認
はサイズ一致を先に調べ、それで一致した場合、MD5値を調べます。
最初はフォルダ内の全ファイルのMD5をすべて出して比較してましたが、それだとファイルサイズが違う＝明らかに別のファイル
までMD5を出すのは無駄な作業なので。
問題はRARとかで1000 000 000(1000M)とかでバイト単位まで決めて分割圧縮してある場合ですね。
これだと大量に1000 000 000 バイトのファイルがあるので、ファイルサイズ一致で省くことができず、全部MD5を出す過程が必要です。
この対策はあんまりないので、一度解凍して無圧縮で1つのファイルに圧縮かけてもらうしかないですね。それか圧縮しないで個別のファイルにして保存とか。
0232デフォルトの名無しさん
2009/06/14(日) 18:23:46前32K中32K後32Kを抜き出してつなげて、ハッシュ計算しろよ
速いぞ
0233デフォルトの名無しさん
2009/06/14(日) 18:27:240234デフォルトの名無しさん
2009/06/14(日) 20:17:46なるほど。DVDに移したファイルをHDDから削除するためのツールってことね。
DVDなんて使ったことないからそんな用途思いつかんかったｗ
0235デフォルトの名無しさん
2009/06/15(月) 15:58:210236デフォルトの名無しさん
2009/06/15(月) 17:23:143日後を楽しみにしてます
0237デフォルトの名無しさん
2009/06/15(月) 19:36:25ソースあるので、修正ヨロ
もしくはブロックハッシュ出す方法(perl)の参考HPを教えてくれ(探したが全部出す方法しか分からんかった。)
0238デフォルトの名無しさん
2009/06/15(月) 20:23:02http://www.geocities.jp/ky_webid/perl5/018.html
http://www.site-cooler.com/kwl/perl/7.htm
0239デフォルトの名無しさん
2009/06/15(月) 20:56:430240デフォルトの名無しさん
2009/06/15(月) 21:08:54補足とか言ってマヌケな計算式のままかよ
こんな繰り返し指摘してもらってるのに理解できなかったのか？
確立計算も出来ない馬鹿が作る削除ツールとか何の罰ゲーム
0241デフォルトの名無しさん
2009/06/15(月) 22:35:280242デフォルトの名無しさん
2009/06/15(月) 23:40:010243デフォルトの名無しさん
2010/03/04(木) 20:30:34なにが問題なんだ?
なんだか分からん桁数のファイル数を扱った場合に発生する天文学的な衝突可能性を気にするなら､
MD5じゃなくてクソみたいに時間がかかるSHA-512で処理すりゃいいじゃん｡
何をどうやっても衝突確率は天文学の領域なんだし､何が問題か理解できんが｡
つうかSHA-1で｢偶然2つのファイルのハッシュが一致｣したら､世界的なニュースになるわ｡
同じSHA-1で､完全に別ファイルかつ壊れてないファイルの発見って､人類が宇宙人と遭遇する確率並だから｡
0244デフォルトの名無しさん
2010/03/04(木) 20:43:50名前が全然違うが､中身は一緒ってのをどうやって検知するか･･･
zip圧縮のzipファイル検知って､微妙にMD5が変わるし｡
中に変なテキストファイルが1個入っただけで｢違う｣となるし｡
AフォルダのA〜Zファイルを全部持ってるBフォルダがあるとき､Aフォルダは削除していいんじゃないかと｡
｢大は小を兼ねる｣判定で｡
もしくはBフォルダ内のAフォルダのA〜Zファイルを削除するのかな｡｢小フォルダを優先｣
(この場合､総集編みたいなフォルダを減らせる)
ややこしいな｡
0245デフォルトの名無しさん
2010/03/06(土) 00:18:110246デフォルトの名無しさん
2010/03/08(月) 23:01:24http://ja.wikipedia.org/wiki/%E8%AA%95%E7%94%9F%E6%97%A5%E6%94%BB%E6%92%83
まず一般的な話｡
MD5=128bitの場合のファイルが偶然一致する確率
これはファイル数の総数で違う｡上のwikiを参考にすると､
3.1 × 10^19ファイル 3100京個のファイル数を持ってれば､
75%の確率でMD5が一致する物がその中に2つ以上あると言える｡
ファイル数が何個もってるユーザーか知らんが｡
1兆個(10^12)もってた場合､MD5が偶然一致してしまう確率はこの表を見ればいい｡
10^-15 〜 10^−12 の間､10^-14とするか､100兆分の1といえる｡
1兆個ファイルを持ってて､それがMD5で一致する確率は誕生日問題を考慮しても
100兆分の1である｡
もちろん1兆個もってない場合､これを遙かに下回る遭遇確率となる｡
0247デフォルトの名無しさん
2010/03/08(月) 23:08:15まずサイズ同一でないのはすべて弾く｡
で､サイズ一緒でかつMD5,SHA1が一緒である確率だが､
サイズが9バイトか､1000Mバイトかでサイズも違うので､
ここでは一般的?な 1Mバイトのファイルで考える｡
1 000 000 下6桁の数字が異なるので､これだけ総数は違うことになる｡
総数が128bit*10^6=3.4×10^44 数あると言える｡これの衝突確率はwikiの表換算で
まあ2で割ればいいので､右が3.1 × 10^22 3桁増えたと考えればいい｡
よって↑の
｢1兆個ファイルを持ってて､それがMD5で一致する確率は誕生日問題を考慮しても100兆分の1である｡｣
を3桁さらに下回る確率
｢1兆個ファイルを持ってて､それがMD5で一致する確率は誕生日問題を考慮しても10京分の1である｡｣
と言える｡
etc(100Kバイト､画像ファイル程度の場合だと､1000兆分の1になる)
>>240 どうですか? 完全に計算しましたよ｡ 10京分の1ってどんな確率か知りませんが(宝くじ1等3億円が300万分の1)
私のファイル重複ツールMD5版の一致確率はこうです｡
で､SHA1版もありますが､これを遙かに数十桁上回ります｡
誕生日問題を考慮してもこれくらいの確率に収まりますね｡
0248デフォルトの名無しさん
2010/03/08(月) 23:17:59まあMD5でもありえない数だが｡<<MD5の一致確率を気にするようなら､
宝くじの当選確率300万分の1なんてあほみたいに｢当たる｣日常的なものなので､
急いで宝くじ売り場に行くことを進める｡
↑そもそもこの前提条件の｢ファイル数所持1兆個｣を達成するのが非常に難しいんだが･･
100キロバイトのファイルを1兆個だと･･･
Gの上のテラの上のペタ､ 100ペタバイトのHDDが必要｡大変ですね｡
0249デフォルトの名無しさん
2010/03/09(火) 00:10:490250デフォルトの名無しさん
2010/03/09(火) 17:35:530251デフォルトの名無しさん
2010/03/14(日) 02:42:550252デフォルトの名無しさん
2010/09/10(金) 15:15:28http://space.geocities.jp/checkoverlap/
0253デフォルトの名無しさん
2010/12/16(木) 08:42:29FileMany
http://codepanic.itigo.jp/FileMany.html
0254デフォルトの名無しさん
2011/01/11(火) 00:11:25｢もうないファイル｣の重複チェックツールがないんだが。
ファイル情報をMD5,SHA1で出力して、そのログを基準に重複チェックしたいんだが。
なんで作らないの？ パソコンにどうでもいいクソファイルを何百Gも貯めとけと？
1度検査したのを、いらないので削除→また同じのを再検査？ あほくさ。
いらないファイル群.txt でMD5リスト作って、それ基準に新規ファイルをどんどん削除すれば
｢以前行った不要ファイル分類｣作業を2度することもない。
このスレで俺が作ったのはそういうツール。サブフォルダはまだ作ってないが、
全サブフォルダの全ファイルにコマンド実行するのは
for /r /d %%i in (*) do
でできるので、これもできるか。
圧縮ファイルは解凍してから重複かけた方がいい。(事前に1回かけて(zip単位)、解凍してもう一度かけると)
zipはMD5いちいちずれる(最高圧縮と無圧縮では同じファイル群を圧縮したのにMD5はずれる)
拡張子でもずれるlzhとrarでは当然違う。rarでも高圧縮と標準圧縮ではMD5が違う
→圧縮ファイルは千差万別なMD5＜＜同じフォルダを圧縮してるだけなのに、かつ中にテキストファイル1つ入ればこれも｢違うファイル｣として重複チェックをかけられない。
解凍前に重複チェックして、解凍後に再度重複チェック。解凍した画像ファイルのMD5が違うことは(編集操作してない限り)そうはない。
0255デフォルトの名無しさん
2011/01/11(火) 00:23:31MD5では厳しいかと思う。jpgファイルだけだと100万ファイル〜1000万ファイルにはすぐに到達してしまう。
リストもばかでかくなる。3000万ファイルのファイルネーム＋MD5リストは1GB以上になる。
処理にメモリも食うしな。
でも作る価値はある。作ります。exe化もできるかな
perlで作ってるが、http://hamachiya.com/junk/memo_PAR.html できたらexe化しますね。
画像ファイルのハッシュ衝突可能性＝重複誤検知(MD5)は>>246より1兆ファイルの巨大リスト時に100兆分の1
画像ファイル1兆ファイル＝100ペタバイト
2010年時点では1億ファイルでも難しいな。2030年くらいまではこれで重複チェックに使えるはず。
SHA1化する合理的な理由がないんだが・・
0256デフォルトの名無しさん
2011/01/11(火) 18:59:53できたんですね。これはいいツールだと思う。
自分用にリストをカスタマイズできればもっといいが。
あとアルゴリズムだが、サイズチェックはどうしてるのかな？
自分はまずサイズでチェック(同一フォルダとハッシュリスト＝サイズも記載)
で、サイズ一致してからハッシュ合一性調査するな
たとえば10GBのファイルがあるとして、この方法だと(サイズがバイト単位で完全一致しない限り)
この巨大ファイルのハッシュを出すまでもない・・
って同じことか。次回にいかすためにはMD5ださないと削除できないので、リスト化をしてるならそれでいいのか。
なるべくファイルサイズあるなら、ファイルサイズかつMD5両方チェックできればいいが、趣味の問題なので(MD5はそれだけで信用に足るとしていい)
まあよく考えられたツールだと思う。がんばりましたね。広まるといいですね。
クソファイルリスト＝ハッシュリスト をダウンすればクソファイル検知もできるわけで、
｢ハッシュ化したのをリスト保存して次回検索に使う｣
はありそうでなかったのでこれが広まるといい。
0257デフォルトの名無しさん
2011/01/11(火) 19:02:42これがなんななのか分からんが・・
■終了時に作成済みハッシュ情報をリフレッシュ（ONを推奨）
作成されたハッシュは
・ハッシュ
・絶対パス付きファイル名
・サイズ
・最終更新日時
の４つが１セットで記憶されており
従ってファイルが移動されると、記憶しているハッシュ情報が次回使えなくなります。
このような古い情報を削除（リフレッシュ）するためのチェックです
？？？ どういうことだろうか。その場限りのリストっすか？ だめじゃん。
0258デフォルトの名無しさん
2011/01/12(水) 10:18:07流れはサイズチェック → サイズ一致してるもののハッシュチェック → ハッシュ一致してるもののバイナリチェック
です。サイズチェックはプログレスを未表示です。ごく短時間で終わるので
設定によって省略されるものもあります
>>257
ハッシュ情報のリフレッシュの意味ですが
ファイルが更新されたら作ったハッシュが古くなりますし
フルパスのファイル名をキーにして記憶しているので
そのパスにファイルが存在しないなどの場合、記憶したハッシュをクリアしています。
なので、基本的に作られたハッシュは覚え続けて次回以降の検索に活かされます
hash.txtの内容は↓
ハッシュ値｜サイズ｜更新日時のTicks｜フルパスのファイル名
0259デフォルトの名無しさん
2011/01/12(水) 19:12:45ハッシュリスト使って重複検知するなら、
上のタブとかに｢ .hash｣を基準にチェックする/しない
とか入れとけば？ コンセプトが分かりやすいし、
ファイル・作業によって作るハッシュリストも違うし、使い分けできるようにした方が良い。
画像とか動画ファイルとか仕事用とか、作業によって作成ハッシュリストも
比較基準用のリストも違うと思う。
チェックタブ(よく使う)は3つくらいあればいいかなー
上に比較用の基準ファイル □[ c:\mydb\gazouhash.txt ]<<iniに記憶する。
下の最下段に出力用 作成するハッシュリスト [ ]＜＜↑と同じ。 変更も可能。
あとハッシュリストはカスタムできるようにした方が良い。
ハッシュ・サイズは不変として、更新日時がいらんやつもいるし、フルパスじゃなくてファイル名だけでいい/直上のパス/ファイル名だけでいいとか。
重複確認
http://www.forest.impress.co.jp/lib/sys/file/filecompare/choufukukaku.html
の方が見た目分かりやすいし。
IEのお気に入りとかクリックすると、すぐにURLがパスに入力されるでしょ。
それと同じで作業別にハッシュリスト・出力リストも分けたいから登録できるようにしたら？
お気に入り＞画像作業＞＝で上にgazouhash.txtで比較、下にgazouhash.txtを出力＞＞次回に生かす。
仕事作業＞で一発ででるとか。その場合の設定も、リストにないファイルは移動するとか、ゴミ箱に削除するとかの設定を記憶して
俺は自作アプリ作るけど、そういう作業別のを完全にカスタマイズして固めて使いわけするつもりだが、
汎用ツールでもある程度｢マイ作業｣別に記憶・設定呼び出し機能あれば便利だと思う。
エロファイルのリストと仕事用のリストは全然別の作業でいっしょくたにできないしなw
0260デフォルトの名無しさん
2011/01/12(水) 19:22:20http://support.microsoft.com/kb/841290/ja
SHA1リスト出力＋SHA1でファイル比較可能。
結構使えるし、組み込もうと思ったが
ファイル名完全一致してることを前提に動作するので、微妙だな。
ファイル名が違ったら違うファイル扱い？ ハッシュわざわざ出す意味ないじゃん。
KBのファイルの検査用にしか使えんな。
0261デフォルトの名無しさん
2011/01/12(水) 19:36:43c:\tesフォルダ内のファイル
パスなし
fciv c:\tes -wp >list.txt
パスあり
fciv c:\tes >list.txt
c:\tesフォルダのサブフォルダも一括して
fciv c:\tes -r >list.txt
で出来る。このリスト使って重複比較すればいいかな。
｢リスト作成ツール｣はもうMSさんが作ってましたと。SHA1もできると。
あとは比較するだけと。
0262デフォルトの名無しさん
2011/01/14(金) 14:46:53http://www.geocities.jp/the13lackart/GRID.html
これはいいソフトですね。
http://www.my-standard.co.jp/1797.html
スピードも速いらしい
0263デフォルトの名無しさん
2011/01/22(土) 21:30:14設定保存つくったんですね。すごいですね。やりますね。
今250万ファイルで重複チェックしなきゃいけない作業してて、
BeRepetition150と比較してみます。
これは400GBの画像で24時間かかる・・
BeRepetitionみたくファイル数カウントもヨロ
あと検索精度の記載がない。BeRepetitionはSHA256とか無駄なことやってるだけなので
(最弱のMD5ですら完全なオーバースペックなんだがw>>246参照)
でも一般人にはこのソフトの検索精度が分からないので、
readmeに書いておいたほうがいい。
>｢1兆個ファイルを持ってて､それがMD5で一致する確率は誕生日問題を考慮しても100兆分の1である｡｣
>を3桁さらに下回る確率<<■サイズ一致兼MD5の複合チェックだと・・
>｢1兆個ファイルを持ってて､それがMD5で一致する確率は誕生日問題を考慮しても10京分の1である｡｣
MD5でサイズチェックの複合化してれば、(MD5のさらに10^5精度が高くなるので)
｢1億分の1の確率(1億円の宝くじは300万分の1)｣＝ゼロ としても、重複を拝むまでには1000000兆くらいのファイル数保持が必要
＝サイズが小さい100KBファイルで 1GBファイルとかだとさらに強度が増す。
と書いておいた方がいいかな。あほみたいなSHA256とかの無駄な競争も収まるでしょ。
まあMD5でこれくらいの確率だとreadmeに書いた方がいい。先頭ハッシュ計算だと強度はそれなりに下がる。
暇会ったら計算したらいい。
0264デフォルトの名無しさん
2011/01/23(日) 16:55:55ハッシュどこで使ってるんだ？
Aフォルダ読み込んで検索でハッシュ作成 終了＝ハッシュリストができる。
Bフォルダ読み込んで検索
A＝Bなんだが(A,Bフォルダ内部では重複してないが、｢さっき検索したAフォルダ｣と同じファイルが入ってる)
で｢重複なし!｣となる。
ハッシュリスト何につかってんだ？ ただのログ？ それで検索はできんのか？
それじゃそこらの重複ソフトと同じだし・・
あと重複ツールって最後の削除時に全部ごっちゃにしてかき混ぜるよね。
重要フォルダ＝削除したくない 新フォルダ＝削除したい なのも構わずごっちゃごちゃにかき混ぜて削除する。
で、｢重要フォルダ＝削除したくない｣のファイルが消失するんだな。1つずつチェックすればいい？
6万ファイル重複してるのを1ファイルずつチェックとか死ねるわw そんだけで5年かかる。
保護フォルダの概念がないってどういうことかな？ ＜＜そういう意味合いもあって｢削除したくないorできない(既にDVDに焼き済みで手元にない)フォルダ｣のリスト化したいんだが、
なんだか分からない論理でファイルの順序を最後にごちゃごちゃにして重要フォルダを｢破壊｣するから怖いよな。
また自分でつくるかな。
0265デフォルトの名無しさん
2011/01/23(日) 17:11:49↓----------------↓
リスト内MD5全列挙 47d0a3c36a0eb8c9c3c57fdebaf7b34f,ae607e940c655e8d7c13cee49b018de9,da44364a643edca504a9d8460108db57
↑------------------↑
D:/A/t.pl 28d5357fda6c2b6a3eae1ddcf75000ef
D:/A/tmp.pl 5c91c17a17f50683be4a27547492be09
D:/A/WS09.JPG ae607e940c655e8d7c13cee49b018de9リスト内ファイルと重複してます!
D:/A/WS10.JPG da44364a643edca504a9d8460108db57リスト内ファイルと重複してます!
D:/A/WS11.JPG 47d0a3c36a0eb8c9c3c57fdebaf7b34fリスト内ファイルと重複してます!
D:/A/焼く前の重複チェック.pl 949873333ab6786a6f96c9d73c398f0a
D:/A/新しいフォルダ/WS1AA0.JPG da44364a643edca504a9d8460108db57リスト内ファイルと重複してます!
みたいな。
まずMD5リストを作って、そのリストを｢指定｣して比較して、重複を削除できると
＜＜つまり削除するのは完全に今のカレントフォルダ(＝正体不明の最近のフォルダ)以下のファイルのみ削除
保護フォルダの概念がある。
0266デフォルトの名無しさん
2011/01/23(日) 17:14:15ファイルサイズ MD5
ファイルサイズ MD5
ファイルサイズ MD5
のリストを作って、それで比較と。MD5以上のセキュリティ強度かつ高速化できるな。
ファイル名とか更新日とかは｢信頼に足りない｣ので無視、リストが500万ファイルとか膨大になるとこうした情報のサイズもバカにならない。
0267デフォルトの名無しさん
2011/01/23(日) 17:28:05設定に従い対象フォルダ以下の全ファイルを列挙
サイズが一致するものをリスト化
同じサイズのものをハッシュ比較
ハッシュも同じものをバイナリ比較
ハッシュ作るまでもないものまで毎回作るって無駄だろ
ハッシュできない＝作る必要ないってこった
0268デフォルトの名無しさん
2011/01/23(日) 17:41:00破壊ってなによｗ
数万個も一致するような状況で使うツールじゃない
しかも１回使ってHDD掃除したら当分動かさなくていいジャンルのソフトだろ？
264には期待してるよ。すげーの作ってくれ
0269デフォルトの名無しさん
2011/01/23(日) 17:49:24に書いてあった
４．検索が開始されます
参考：アルゴリズム
a．検索対象ファイルを全て列挙
b．ファイルサイズの昇順にSort
c．同じサイズのファイルが２つ以上ないものは候補より除外
d．サイズが一致するものを重複ファイル候補とします
e．ハッシュ比較がONであればさらにハッシュで比較を行います
（この時、既にハッシュ作成済みデータがあればそれとの比較）
f．１バイト単位で完全一致比較がONであれば全データをバイナリ比較（※１）
0270デフォルトの名無しさん
2011/01/24(月) 22:41:58焼いたファイルも｢掃除｣の一種
DVD等に焼いて手元にないファイルも｢パソコン内｣と見なす重複検知ツールが市中にないってこと。
焼かないやつでも外付けHDDに入れたのとかあるでしょ。HDDいちいち全部つけるの？
>>269
やっぱそれじゃぐちゃぐちゃになるよね。ファイルサイズでソートしちゃうんだ？
それをまた並べてもフォルダがごっちゃになるわな。｢可能性｣があるだけでも怖い。
たとえばちゃんと整理して綺麗にしたフォルダがある。新しいフォルダ(最近ネットで落としたのとか)がある。
それで｢整理したフォルダ｣と｢新しいフォルダ｣を重複検知したら整理フォルダのファイルまで破壊されたんだが・・
また整理しろと？ どこに何があるかも分からないのに、
あと歯抜けフォルダが大量にできたりとか・・
バカじゃねーの・・ 整理されてないフォルダに対して重複検知するんだから、フォルダ名・階層が綺麗とは限らん。
そこらへんのとこも考えて欲しいな。
0271デフォルトの名無しさん
2011/01/24(月) 22:52:08重複一致画面で順番が信頼性に足りないから、途中で反転してたりする。
Gドライブのファイル(新しいフォルダ)にずっとチェック入ってたのが、なぜか反転してEドライブ(整理済み)に入りだしたり・・
20万ファイル重複とか、1つずつチェックなんてできるわけがない。
やろうとしたが、あほくさくてやめた。200個で1ページのPageDownが1000回くらいかかりそうでw
拡張性も考慮してほしいな。無駄にファイルパスとか入れてるからメモリ溢れて停止するんだが。
とりあえず1000万ファイルは扱えるようにしてほしいな。
｢DBを作る｣のが目的。画像ファイル集めてたら100万とかすぐに超えるだろ。
本質的に｢焼いたファイル｣と｢いらないゴミファイル｣の区別はない。
そういう｢既にチェック済み｣のファイルを再チェック不要で、作業前に削除するのが重複検知ツールの目的。
だから｢持ってる旧来のファイル｣を消しちゃだめだ。
0272デフォルトの名無しさん
2011/01/25(火) 00:24:40結果の見せ方は工夫できるだろうが
万単位で重複とか1000万ファイル扱えるようにとか（DB作るのか？
.NETのライトアプリには荷が重いし
はじめから271が求めてるスペックのアプリじゃない
もっと最初から想定した設計実装じゃないとだめ
パスは削除するファイル選ぶ材料になる。常に見えてる必要はないが
あとあほくさくならないインターフェイスってやつを考えて示してくれ
誰か作ってくれるかもしれんぞ
持ってる・いらないファイル.txt
######################
md5,ファイルサイズ,etc(ファイル名)
md5,ファイルサイズ,etc(ファイル名)
################
でリストを作る。
md5,ファイルサイズ だけでいいと思うが。
でこのリストのMD5 ファイルサイズから重複判定するだけ。
リスト作成で8割できたようなもの。
あとそのリストをどう処理するかはアプリを問わない。.NETだろうがVBだろうが同じ。
｢リスト優先主義(パソコン内ファイルだけじゃなくて、リストもファイル群とみなす)｣にしましょう
ってだけ。パソコンにおけるファイルなんてたかがしれてるし、
｢いらないファイルをPCに置きたくないだろ。｣あほらしい。HDDの無駄。
ウイルスとかグロ画像とかもう一度見ろと？ みたくもないよ。
｢これはいりません・orもう持ってます｣という情報だけを保存・整備したいだけ。
｢ゴミとして捨てたものを、また見つけて削除する｣って、前にやった作業をしたくないだけ。
0274デフォルトの名無しさん
2011/01/27(木) 10:59:20簡単な一覧、編集ツールつければできそうだな
重複じゃなくていらないファイルを探して削除する。と
需要ありそうなら検討よろ
前みたらゴミだった.txt＝ゴミだからいらない、その場で削除
ファイルサイズが未知→MD5チェック→両方未知＝ユニークファイル＝？？なのでとりあえず残す。
結局そのファイルはいらないわけで、持ってる＝ゴミ どっちも同じ事なのでリストは1つでもいいけどね。
所持ファイル(MD5,ファイルサイズ).txt
とくに画像ファイルは2つ3つ以上MD5が一致したら｢同じフォルダ認定｣でいいのかな。
動画ファイルは末尾が違う場合もあるから先頭データがいるとか？
動画はいいや。MD5,ファイルサイズだけで
0276デフォルトの名無しさん
2011/01/27(木) 20:37:52100KBの画像だけで1000000ペタファイルくらいいるんじゃね？
100万分の1にするために必要なファイル数は2.6 × 10^16セットらしい
10^16=京
2.6京ファイル数の100KB画像は何バイト？
2.6*10^15MB=2.6*10^12GB=2.6*10^9TB=2.6*10^6PB=2.6*10^3EB=2.6ZB
テラの3桁上のペタの3桁上のエクサの3桁上のゼタバイトです。
1GBの動画ファイルだとさらにファイル容量が必要で2600ゼタバイト＝2.6ヨタバイトです。
10年で3桁HDDの容量が上がるとして、今はTBなので2020年にPBで 2030年にEBで 2040年にゼタバイト。
2040年くらいに100万分の1になっちゃうね。
全部100KBのファイルの場合なので、実質もっと上だし、2050年くらいかな？
今何歳か知らないけどMD5が使えなくなるまで生きれるといいね!
最短でも2060年かな。
0279デフォルトの名無しさん
2011/05/12(木) 17:49:03.740280デフォルトの名無しさん
2011/05/14(土) 00:58:22.63ここでも読め
0281デフォルトの名無しさん
2011/05/14(土) 01:01:20.19UnDup1.5とBeRepetition1.5とFileMany1.1.1.4bな
正確にはUnDupはシェアウェアだが試用制限試用期限無しの事実上のフリーソフト
こんな事言ったら作者に叱られるが
0282デフォルトの名無しさん
2011/05/15(日) 10:21:45.99Beなんとかはハッシュ方式が選べるのがいいのかな
FileManyは更新が続いてる
用途に合わせて使い分けるとこの辺が選択肢か
類似画像検索もできるといいんだがスレチか
0283デフォルトの名無しさん
2011/05/15(日) 14:19:51.03他にもいろいろあるよ
DeDup
http://cosmosa.jp/1215677534.html
FileHammer
http://mebiusbox.crap.jp/software_file_hammer.php
でぃぷりーで
http://www.oohara.jp/ppp/dup.html
Auslogics Duplicate File Finder
http://www.panda.co.jp/auslogics/duplicate-file-finder/
探せばいくらでも出てくる
正しく使って大事なファイルを消してしまなわいように
0284デフォルトの名無しさん
2011/05/19(木) 15:14:11.82２ＧＢ超のファイルがあると異常動作する。
きっと他にいいソフトがあるんだろうけど、
ひとつひとつダウンロード・インストール・試用・・・
とかメンドクセー
0285デフォルトの名無しさん
2011/05/19(木) 15:41:02.04BeRepetitionは信頼性は高いけど遅い
FileHammerは.NETではなくネイティブアプリでサムネイルも見れるし速度もFileManyとだいたい同じ
いろいろルールを作って記憶させておける点がいい
もし自分で作るならFileHammerみたいなソフトにしたい
0286デフォルトの名無しさん
2011/05/21(土) 01:27:47.93みんな忙しいのか
0287デフォルトの名無しさん
2011/06/20(月) 01:29:25.64FileManyはかなり速いが
設定項目が少なすぎな点が痛い
あと削除条件の動作があやふや
油断してると重複ファイルがあると両方消されで無くなるから困るｗｗ
0288デフォルトの名無しさん
2011/09/18(日) 23:10:18.71Image Compare Ver.1.3.lzh(040708)[近似画像を抽出]Vector ※階層ファイルを読み込まない
DRE 2011-02-12 バージョン 0.2.1[類似画像検出ソフト]類似画像検出ソフト DRE ※Javaをインストール
フォルダ内のファイル比較ツール 6.14 FdateCompare.zip ファイル テキストファイルの比較 ※検索出来ない
重複確認 ver 1.50 重複ファイル比較管理ソフト ※プレビュー画面が何回も表示
重複画像チェッカー 0.0.1 ImgChk001.lzh 2003.10.6 ※階層ファイルを読み込まない
重複画像カッター ver 1.5.3 2011/04/26 重複画像チェッカー ※階層ファイルを読み込まない
Easy Duplicate Finder 重複ファイル検索ソフト ※ setup.exe インストール
画順化計画(簡易版) 1.14 ※フリー版 setup.exe インストール hfImgCmpK114.exe
Gcomp Ver. 0.10 gcomp.lzh 画像比較ソフト ※
Sias ver1.11(051203)[画像を登録フォルダに整理するソフト]Rebla ※使いにくい 更新無し
MME Super Ver3 2011/04/22 マルチメディア画像・音楽・動画等を管理・表示（再生）※ setup.exe インストール
Competent Media Player 5.11 10.1031 標準で約30種類のメディアファイルを再生 ※ D＆DでMP4 MKV再生不可
Astute Picture Manager 1.01 11.0201 エクスプローラー型画像ファイルマネージャ ※ 使いにくい D＆D不可
ALBM 1.66 10.06.13 画像ファイルを一覧表示しながら整理・閲覧・印刷 ※ 使いにくい
仕分ちゃん 1.10 2010.3.14 shiwake.lzh ※ 使いにくい
PortalFolder-0.1.0.zip 2010-08-06 複数のフォルダへの移動、コピー ※ フォルダ登録がD＆Dや複数で出来ない
ComicPicker-0.6.3.zip 2011-09-11 画像書庫ファイル、画像、PDF 文書を閲覧、整理するツール ※ 削除や移動が一つずつしか出来ない
Filemater-0.2.0.zip 2010-08-08 ファイル整理ツール ※ 使う機会が無い
MebiusScope-0.1.0.zip 2009-02-15 マルチメディアビューア。テキスト、バイナリ、画像、PDF、動画、音楽、HTML, ハッシュ ※ 使う機会が無い
FolderHammer 1.2.0 2010-08-01 フォルダ削除ソフト ※ 使う機会が無い
Mebiusbox-1.9.1.zip 2010-08-01 ４画面なリネーム機能４画面なリネーム機能ファイル管理ソフト ※ 内蔵ビューアが直ぐに落ちる
0289デフォルトの名無しさん
2011/11/14(月) 21:58:32.840290デフォルトの名無しさん
2011/11/15(火) 01:18:37.75C#で書いてあるらしいけど一番動作が速いようだし
どういう訳か3日に1度ほど更新してる
0291デフォルトの名無しさん
2011/11/15(火) 07:43:45.83なにそれ怖い
0292デフォルトの名無しさん
2011/11/15(火) 11:54:33.52斬新だなwww
思いつかなかったわww
0293デフォルトの名無しさん
2011/11/15(火) 20:25:53.48ＡｖｓＢ → Ａを消す
ＢｖｓＣ → Ｂを消す
ＣｖｓＡ → Ｃを消す
みたいなのが出来上がるんだぜ
0294デフォルトの名無しさん
2011/11/15(火) 22:38:05.59ファイル数31.6万、約170GB、重複数178というフォルダで比較してみた。
バイナリ比較での測定ね。
SDFMach 1593秒（デフォルト）
FileMany 3213.2秒（1バイト単位で比較）
ソフトウェア板の方にもFileManyが速いって唐突に言い出した人が前にいたんだよな。
その時も、俺がUnDup、SDFMachと比較したんだが・・・
前より速くなったけど、遅いとしか言いようがない。
0295デフォルトの名無しさん
2011/11/16(水) 04:58:33.31JITコンパイラで糞みたいなコード吐いてるだろ
0296デフォルトの名無しさん
2011/11/16(水) 08:06:55.680297デフォルトの名無しさん
2011/11/16(水) 19:08:01.770298デフォルトの名無しさん
2011/11/16(水) 20:16:31.81やってみた。
ファイル数 316535、約168GB、重複数 180というフォルダでの比較。
バイナリ比較での測定ね。
すべて現時点での最新版を使用。
設定はだいたい同じ条件になるように（たぶん）してある。
検索結果は同じだった。
DupFileEliminator 588.1秒
SDFMach 1595秒
FileMany 3093.3秒
やけに速いな。
DupFileEliminatorもC#らしい。
0299片山博文MZ ◆0lBZNi.Q7evd
2011/11/17(木) 16:10:25.980300片山博文MZ ◆0lBZNi.Q7evd
2011/11/17(木) 17:07:01.29フルパスファイル名の比較で両方とも消さないようにできるはず。
0301デフォルトの名無しさん
2011/11/17(木) 18:05:35.810302デフォルトの名無しさん
2011/11/17(木) 18:37:55.390303デフォルトの名無しさん
2011/11/18(金) 18:23:08.880304デフォルトの名無しさん
2011/11/18(金) 18:31:19.70これなら数日で作れそうだ。
0305デフォルトの名無しさん
2011/11/19(土) 15:19:58.430306デフォルトの名無しさん
2011/11/21(月) 22:29:42.400307デフォルトの名無しさん
2011/11/23(水) 18:07:43.08だから画像フォルダなどあまり変化がな所は検索すればするほど速くなるみたいだ
DupFileEliminatorは起動毎に一から検索をやり直す
だから初回起動時は一番速いが徐々にFileManyに抜かされるように思える
HDDの使い方にも大きく左右されるけどな
0308デフォルトの名無しさん
2011/11/23(水) 23:06:14.88やってみた。
フォルダは>>298と同じ。中身は全く変わっていない。
前回のハッシュリストがそのまま残っているので2回目として再計測。
DupFileEliminator 588.1秒
FileMany 3093.3秒
648.6秒（2回目） ←New!
以前のバージョンだとハッシュリストを上手く使えてなかったけど、
今は有効に使えるようになったみたいだね。
3回目も計測したけど同じ結果だった。
フォルダの中身が同じなら2回目以降は同じになるのは当たり前。
何度計測してもこれ以上速くなることはないかと。
0309デフォルトの名無しさん
2011/11/23(水) 23:55:22.20サイズと日付けと何かであっさり比較諦めてバイト単位でみてないだろ
実際バイナリエディタで改変したら重複判断してワロタ
0310デフォルトの名無しさん
2011/11/24(木) 10:24:54.97表示されるサムネ見てみ
明らかに違う画像を同一ファイルと判定する場合がちょこちょこある
0311デフォルトの名無しさん
2011/11/24(木) 22:34:49.200312デフォルトの名無しさん
2011/11/26(土) 10:00:09.540313デフォルトの名無しさん
2011/11/26(土) 10:15:12.20すごい勢いでバージョンアップを繰り返してるし
0314デフォルトの名無しさん
2011/11/26(土) 13:36:10.35類似じゃなくて重複の方での誤判定って事だよね？
いろいろ試してみたんだが、こちらでは誤判定するパターンを見つけられなかった。
誤判定するサンプルファイルを提示してもらえないだろうか。
0315デフォルトの名無しさん
2011/11/26(土) 15:04:07.69カンパウェアの癖に
0316デフォルトの名無しさん
2011/11/26(土) 15:28:01.690317デフォルトの名無しさん
2011/11/26(土) 18:02:47.37類似じゃなく重複で誤判定。再現方法は
動画みたいに100MB単位のデカイファイルを１つ用意
んでコピーする。このままだと重複
バイナリエディタでファイルのどっかを１バイト改変
更新日時とかが更新されるから
フリーソフト使って作成日、更新日、なんかを揃える
で、重複チェックすると重複と判断される
0318デフォルトの名無しさん
2011/11/26(土) 19:57:41.02sha256までは一致しないだろ
0319デフォルトの名無しさん
2011/11/26(土) 20:00:09.62ありがとう。 バージョン 20111016 で、メタデータ無視機能を使用してます？
該当するようであれば、20111106 を試してもらえないでしょうか。
0320デフォルトの名無しさん
2011/12/04(日) 22:57:17.040321デフォルトの名無しさん
2011/12/04(日) 23:54:32.89SHA256
時間はコンビニに出かけていて測ってないが、メモリは本当に食わないね
時間はさすがに掛かる
CPUはハッシュを計算している時30％ほど食っていたが比較中は5％程度
C#のライブラリが良く出来てるんだな
つーかSHA256を計算するのも
http://msdn.microsoft.com/ja-jp/library/system.security.cryptography.sha256.aspx
これがあるからなあ
ほとんど計算部分はプログラム必要ないじゃん
C/C++で書いたら大変だよこれ
0322デフォルトの名無しさん
2011/12/05(月) 00:04:31.45なってワロタ
表示にかなりのリソース食ってるな
0323片山博文MZ ◆0lBZNi.Q7evd
2011/12/31(土) 12:45:21.81http://www1.axfc.net/uploader/Sc/so/305512.zip
0324デフォルトの名無しさん
2011/12/31(土) 13:31:29.270326デフォルトの名無しさん
2011/12/31(土) 15:42:50.39もーいいよ
0327片山博文MZ ◆0lBZNi.Q7evd
2012/01/02(月) 13:59:30.93http://katahiromz.web.fc2.com/duperase/
0328デフォルトの名無しさん
2012/01/02(月) 23:59:32.99作ろうとしたが失敗した
0329デフォルトの名無しさん
2012/01/09(月) 17:48:04.46チェックサムやパリティーを使えば良くないか？
4byteか8byteづつ読み込んでXOR演算をしてやれば32bitか64bitの数値が手に入る。
後は、全体が一致しているか調べるだけ。
0330デフォルトの名無しさん
2012/01/09(月) 20:29:09.480331デフォルトの名無しさん
2012/01/09(月) 21:21:51.58衝突はしないと思うが、SHA-256の計算量ってチェックサムと比べるとどの位多いんだ？
0332デフォルトの名無しさん
2012/01/09(月) 21:43:54.03いくらでもサンプルプログラムが転がってるだろうが
でもテーブルを利用してるからそんなに多くはならない
0333デフォルトの名無しさん
2012/01/11(水) 01:01:58.46対する再検索が、ディスクのアクセスランプもほとんど点かないで、ほぼ瞬時
(数秒〜10秒)で終わるんだけど、どこかにキャッシュしているんでしたっけ？
ちなみに検索設定は完全一致(1pass)で、PCを再起動した時の初回検索には、
同じ対象で重複を検索するのに5分強ほどかかります。
キャッシュした計算済みのハッシュを使う方法は、ファイルリンクの破損や
ウイルス感染、ファイルの上書き更新など、なんらかの原因でハッシュ計算
後にファイルが書き換えられている可能性を完全には排除できないと思います。
それと、ハッシュ値は1回のテーブル参照では求まらないので、シーケンシャル
アクセスで単純にバイト列を加算していくチェックサムに比べて、計算の手間は
膨大になります。
ファイルが大きくなるほど、同一サイズのファイルが存在する可能性は減る
ので、現実的な範囲であれば、サイズでふるいに掛けて、サイズが一致する
ファイル同士のみを、総当たり戦で完全一致で比較するほうが確実で早いと
思います。
0334デフォルトの名無しさん
2012/01/11(水) 01:40:25.97FileManyは使えば使うほど速くなる
でも時々hash.txtを消してやらないと残しておきたいファイルも過去に存在したと
いう理由で消されてしまうので注意
だんだん起動と終了がhast.txtの読み書きのために遅くなって行くしな
0335デフォルトの名無しさん
2012/01/11(水) 02:13:45.06実は、UnDupに似せたUIの自作のファイル重複ツールを途中まで開発して
もう3年くらい放置しています。
ファイルの完全比較による重複ファイルの検索アルゴリズム部分しか作り
込んでいませんが、手元にあるテストデータでベンチマークしてみたところ、
おおむねUnDupより2〜3倍くらい速いです。
テストに使ったデータはネットから落とした画像ファイルで、対象ファイル
総数が約32000個(容量の合計は約100GB強)、そのうち重複ファイルは465種類
(937個)で、重複ファイルのサイズは180KB〜26MB(合計では2.7GB)とまちまち。
上記の条件で、UnDupだと完全一致(1pass)で5分ちょっと掛かりますが、作り
かけの自作のツールだと1分30秒もかかりません。 ただし、再検索でも毎回
ディレクトリ探索とファイル読み込みを行うので、2回目以降も検索速度は
ほとんど変わりません。
ちなみにFileMany(Ver 1.4.3.1b)により完全比較(MD5を含む)だと、ハッシュ
のない初回で4分ちょっとでした。
完全に突き合せての比較はしていませんが、重複結果の種類とファイル数は
他のソフトと同じです。
VC++(MFC)のダイアログベースアプリで、ソートは標準ライブラリのqsortを
呼んでいます。 ただし、検索結果をバッファへ記憶する際に配列要素の拡張
でオブジェクトのコピーが発生しないように注意を払い、すべてポインタ管理
にしています。(ソートも実体ではなくポインタを並べ替えるので要素が増え
ても速い)
0336デフォルトの名無しさん
2012/01/11(水) 03:12:42.88期待している
俺が作るとしたらC++Builderでササッと作るけどな
MFCは結構面倒くてどうしてもVCLの手軽さに負けてしまう
0337デフォルトの名無しさん
2012/01/11(水) 17:50:27.960338デフォルトの名無しさん
2012/01/11(水) 18:08:54.660339333=335
2012/01/11(水) 23:50:34.78にもう少し作り込んでから公開します。 アップロードしたら、あらためて
ここで告知させてもらいますんでよろしく。
画像の類似検索はOpenCVを使う予定で、幾つかアイデアはあるけど、試して
いる時間がない。
0340営利利用に関するLR審議中＠詳細は自治スレへ
2012/03/30(金) 15:42:37.41■ このスレッドは過去ログ倉庫に格納されています