ファイルの重複検出ツールを作ろうぜ

CD、DVD、HDDなどのファイルハッシュを計算しておきデータベースを作成して照合する
初めに64KB程度読み込んでハッシュを計算して、それが一致したら1MB程度ぶんずつ照合していく
ハッシュの計算方法は高速で、異なるファイルは異なる値を出すようにしたい
いちどブロックソーティングするといいとおもう

前に自分で立てたスレがあったよ　すまん

では、ここではブロックソーティング中心に研究します
解説サイトをあげておきます

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

32KBから10MBまでのファイルをビット列と見なして、ブロックソーティングの符号化、復号化をなるべく高速に行うプログラムをつくろう

ソートの仕方は、例えば2進数　1101が与えられたとき
この巡回データ　（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進数の幅が大きい場合は、ランレングス圧縮 して登録するとよさそうな気がします

ブロックソーディングがしにくいのは、00000000000000000000000000000000とか
10101010101010101010101010とかのデータが出てきた場合
どうすればいい?

日本語テキスト、英語テキスト、exeなど別に辞書を作っておいて一度圧縮してからブロックソーディングいいかな?

>>1
宿題スレにレス来ているよ。

8ビットずつに区切って、ファイルごとに出現回数を求めて、類似するものを纏める
つぎに同分野ごとに出現回数からもっとも縮まる単語帳を作る

>>1
>いちどブロックソーティングするといいとおもう
なぜブロックソーティングするのか理解不能。
何も考えずにmd5でも計算したほうがよっぽど速いだろ。

今使ってる重複検出ツールはまずファイルサイズで確認するよ。

>>10
例えば、先頭1KだけでCRC計算するより、10Kを1Kに圧縮したものでCRCを計算した方がいいっていう発想
先頭が例えば空白ばかりのファイルが沢山あると区別がつかない

単発作ろうスレ立てるな上げるなリアルで死ね

>>10
やっぱそのまま64Kとか100Kくらいをハッシュ関数にわたしたほうが良さそうだな

重要なのは、合計のかかる時間なんだ
ファイルの読み込み、ハッシュの計算、比較の時間
どこにどの位時間をかけるかが重要だ
ファイルを沢山読めば、間違える確率は減るがそれだけ計算時間、読み込み時間がかかる
減らせば一致するファイルが多くなりこちらも比較に時間がかかる

よしまずは、ファイルの先頭何バイト読み込めば異なるファイルだと判別できるか確かめよう

先頭32Kでほぼ比較は出来るらしいことが判明した

32Kを直接比較するのと、SHA512やMD5に変換して比較するのではどちらが速いのか?

ハッシュですべき

ファイルの先頭から32K程度だと、動画の場合でオープニングシーンがある場合は比較が難しい
(オープニング/タイトルシーンは同じ場合であることが多いから)
ある程度ファイルのオフセットを取ってから比較すると32Kも比較しなくていい場合もある
ここらへんは、1.まず最初にファイルサイズが一致したら、2.先頭32Kを比較しても一致したら、
3.オフセットを取って比較ぐらいにするといいかも

同速度のHDD2つ、またはHDDとDVDを検索するとする
一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする

ファイルサイズと、CRC32を記録しようとすると一ファイルあたり8バイト必要
ファイル数は2^24個なので必要メモリは、最大128MB必要になる
これはスワップアウトを引き起こしてのろくなる原因になりうるが対処法はあるか?

ファイルの読み込みをドライブ別に読み込めば速度が出そう

板違いｳｾﾞｰよ

CRC16にしておけば、最大96MBで実用的か
あと肝心な事を忘れていた　ファイル名とそのパスを記録する必要がある　ここが一番メモリを消費する
ディレクトリ名は255文字位使えたような気がするのでメモリをくう
ハードディスクの格納方法を知ることが出来れば、文字列を全て記憶する必要はなさそうだが・・・　
あとあらかじめサイズなどで比較の必要がないものはCRCの記録までやらなければメモリは減らせるが・・・
しかし、ディスクのシーク時間を考えると、一度ファイル名やサイズを取得したら一緒に32Kくらい読み込んだ方がとくということもある

>>19
ファイルのオフセットとは何でしょうか?

オフセットってのはファイル先頭からの距離の事

MD5の値を使って、ファイルの重複をチェックしている。データベースには700万個の
ファイルが登録されている。
最近、複数マシンに渡ってファイルを比較する機能を追加した。

>>1のプロファイル

・ヒキオタニート
・テラバイト級のストレージを持つ極度のny厨
・秘蔵のロリ画像・動画の収拾がつかなくなったから重複検出をせざるを得なくなった

挙句にム板でオナニースレとかどうしようもないゴミだな。

同一フォルダにおけるファイルとフォルダの合計数は、2^32-1個らしい　明確な記述は見つからなかったが・・
しかし、2^16個以上ある場合は無いだろうから、(a, b, c, ・・・)　abcは2バイトの数字でファイルの位置は表せるな
ツリー構造を表現できれば、親ディレクトリの情報は共有できる

>>23
>>19のいうオフセットの比較がわかりません

ここいいよ
日本で現在最強の検索ツールundupの作者の開発ノートが置いてある
http://hp.vector.co.jp/authors/VA032597/Software/TechNote.txt

ファイルのパスだけど、一階層ずつ32ビット使ったとしてもある程度たまった時点でディスクに保存してしまえばメモリの消費から除外できるな
利用するのは最終的に重複ファイルが決まったときのみだからメモリにおいておく必要なし

>>26
多分「オフセットを取って比較」ってのは「ファイルの先頭から一定の距離に位置するデータを比較」の意味でしょう。
「ファイルからオフセットを取得して比較」（？）じゃなくて。

まずはドライブにあるファイルの、ファイルサイズと　先頭32KBのCRC16をメモリに格納する部分を作ろうぜ
ディレクトリ構造も保存しておいた方が良いけどコードがが煩雑になる　これも入れたやつで速度を測った方が正確か　
だれがもっとも速いアルゴリズムが作れるか競おう

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
意味理解しました　しかしずらして比較するくらいなら、一度の多くを読み込んだ方がシーク時間が短くなりそう

>>27
そこのソフトの人の解説流し読みしたけど、かなり幼稚な印象だけど。
自画自賛？というか、もしかして1本人かな・・・
ファイルみたいな総数の判らん対象をオンメモリでソートなんて
やってる時点でソフト寿命はたかが知れてると思うよ。

>>27>>30
他のソフトと比較した上で言ってるの？

>>1とりあえず mail欄にsageっていれて投稿して
1,まず他のファイル重複検知ソフト(同業他社)が実装をどのようにしているのかのチェックを>>1はしたの？
2,ブロックソートとか行うと他のソフトとのハッシュ値の互換性がないけどどうするの？
　>>1が作成したアプリケーションでしか、ハッシュ値の計算ができなくなるけど…
3,代表的な使用用途・検索するファイルの数/ファイルサイズ・ハッシュ結果のバイト数をできれば教えてください。

>>31>>32
日本一のファイル比較ツール作者のノートを読みましたよ 他のツールと比較しましたよ

>>32
ブロックソーティングはやめました
ハッシュ地に互換性は入りません　そもそもファイル全体のハッシュ値では無い為、他と一致するわけがありません


>>32
条件はこれにしましたよ

同速度のHDD2つ、またはHDDとDVDを検索するとする　一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする

すみません　Janeでsageほ固定しました　以後気をつけます

>>33
比較した他のツールってどれ？

>>35
このへん　対抗馬ってなかなか無いよ　まともに動作しないのがほとんど　ここ一年程度のは調べていないが・・・
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

最近のやつしらべたら良さそうなのがあった　上はUNDUPとそれほど変わらないかも

http://www.vector.co.jp/soft/win95/util/se257049.html
http://lucky.na.coocan.jp/ddchecker.html

>>36
あとできればまともに動作しなかったのもおながい

ほとんどのやつはいい加減か動作が鈍い　ファイルサイズしか調べなかったりする

>>33
レスありがとう。Image Hash Search みたいなものを、作るのかなと思ってたんだけど。
そうではなくローカル環境で動作する重複ファイルの検知ソフトを作るということだよね？

あと>>1で書いている重複という言葉は「バイナリレベルでの完全一致」ということでいいの？
たとえば画像とかの場合はヘッダーだけ違って中身は同じというファイルも多々あるのだけど。

私の質問がわるくてごめん。>>32の3はソフト使用者がどういう用途で、
パソコンを使用しているのかを考慮して、重複検知ソフトを作っているのかという話だったりします。
変な例で悪いけど、P2P使用者とそうでない人ではHDD内にある主なファイル種類・サイズは違います。
よってソフトもそれを考慮して最適化する必要があります。

『ほとんど』
って言葉できるだけつかわずに説明おねがい

>>40
バイナリの完全一致ですよ　ファイルの種類での分類は考慮しない方向でいいと思います　
というのも異なる種類なら先頭の方で不一致するからです

>>41
ほとんど　＝　UNDUPや上に上げたソフト以外

>>39
具体的に

ｇｄｇｄ

いい加減なツールは　>>36にある

調べた時の条件は？

>>1しか読んでないが、ファイルサイズとMD5を保存しておいて比較するだけでいいんじゃね？

>>47
3GのMD5を計算するのにどれくらい時間がかかるんだろか? なるべく高速、低メモリが重要

目的とか目標って何なの？
既に高速なツールはあるけどもっと高速なのを作りたいの？

以前PerlとMySQLで、エロ画像の重複チェックしてたなぁ。
飽きて放置したまんまだけど。

既に高速なツールあるとはどれですか?

>>48
こういうのって重複したファイルを削除したいってのが目的だから、
サイズの小さいファイル(数百KBの画像とか)をターゲットにしているんじゃないの？

そこらへんが>>1に書いてないからよーわからん。

>>52
サイズ小さくても、ディスク一杯に詰まっていたら、500G程度読み込んでMD5を計算することになるよ
なるべくディスクの読み込みを減らして比較できた方が良い

1kb〜数gbのどんなサイズでも最高速に動くアルゴリズムなんて
30秒で思いつかなきゃ素質ないね。

>>43
いい加減なソフトが多いのは事実だと思うよ。
・なにをもってファイル重複としているのか、マニュアルなどに書いていない。
・NTFSのリパースポイントをソフト側で考慮していない。
すぐにあげれる問題としてはこんなとこ。

ルートディレクトリ(c:\)を入力したら、ファイル名とサイズと先頭32Kを読み込む
ファイルは読み込んだ順に連番をつける
ファイル名とその配置、ディレクトリ名はディスクに書き出し、ディレクトリ名とファイル番号とサイズとCRCはメモリに保持する　
ディレクトリがあれば最後に進める　いくつまで進めたかを記録しておく
調べるディレクトリがなければ上へ戻る

もうｇｄｇｄって感じだな

所詮割れ厨だしな

>>56
最初からファイルの先頭読んでく必要ないでしょ。
同一サイズのファイルが出てきた時に初めてやればいい事だし。
つーかアルゴリズムもっと勉強しなさいよ。
辛いんだよこのスレ＞＜

>>59
>>27をよんで下さい　
ディスクのシークにかかる時間を考慮すると、その位置にある時にまとめて同ディレクトリのファイル内容を
取得してしまった方が速いようです　

ここです

ソートを行って検索すべきファイルを減らした後で、今まではファイルサイズの順番に従って検索していたのを、
ディレクトリの並び順にCRCを計算していってメモリに記録し、後でファイルサイズ順にCRCを比較していく事にした。
テスト環境では従来の完全比較に比べ半分以下の時間ですみ、簡易検索の後に残った重複している可能性のある
ファイルを完全検索しても充分にお釣りがくる結果となった。
実際にはＭＯの様な極端にシークが遅いのでランダムアクセスが大きな負担にならない様なメディアや、
ほとんどが重複していて簡易検索では候補を絞れないためその後の完全検索で時間がかかり過ぎる場合など、
この新方式では高速化されないケースもある

なるほど。
エントリ読みに行ったついでにクラスタサイズ程度読むのは有効かもな。

基本はwindows APIを直接使う方がいいだろうな　速度的に　いま>>56を作っている

普通に作ると一度実行するとファイルの中身がキャッシュされるので、メモリに収まるような少量のデータでテストすると１回目と２回目以降ではDISKアクセスに関してはまったく異なる挙動になります。
そこも考えてプログラムもテスト用データも作る必要がありますよ。

とりあえず簡単の為にCreateFileで一度アクセス出来なかった物は存在しないものとしよう　
しばらくしたらアクセス出来る物もあるとは思うが・・・
CRCの計算、ファイルの読み込み、ファイル情報の書き出しを並列化できるとおもう
情報の書き出しはある程度サイズが貯まったらにして、CRCの計算はほとんどかからないだろうから
実質的には読み込み時間だけですむと思う

あともっとも時間がかかるのは、サイズのでかいファイルが一致してしまう場合なんだよな
1Gのファイルが一致すれば、まともにやると2Gぶん最後まで比較しなければならなくなる
最大、比較サイズを決定してしまうという方法はある　たとえば全体の30％　OR 100M　一致すればあとは検査しないとか
あとは、1MずつにCRC計算しておいてデータベースに入れておけば半分ですむ

>>63
テストデータは作るの難しいと思うので直接CやDドライブを実験台にしようと思います

わざわざBBSに独り言を書き込まずにはコーディングできないのかね

1Kバイトのファイルが10万個とかある比較がと大変だな　同サイズのファイルはせいぜい1万個くらいな気はする
小さいファイルを沢山生成してテストするか　こうなると中身を読んだ方が断然いい

頭大丈夫か

unixのコマンドの組み合わせでできたような
http://en.wikipedia.org/wiki/Fdupes
winで動くのもあるね

http://fx10.web.fc2.com/testdata.zip

テストデータを生成します　5分ほどかかるかと思います

現在最速ソフト
http://www.vector.co.jp/soft/win95/util/se257049.html

第二位
http://www.vector.co.jp/soft/win95/util/se257656.html

ハードディスクの内蔵キャッシュは書き込み、読み込みなどを高速化するように並び替えするの?
それとも書き込む順番どおりなの?

CRC32の計算方法とテーブルってわかる人いますか?

http://kone.vis.ne.jp/diary/diaryb07.html

ここらへんにかいてあるが不明

はやいコードをコピペすればいいか

途中まで書いたが眠いので途中までしか無い

m ディレクトリの階層の深さ　
n 見つかったファイル総数
M 最大階層数
N 最大ファイル総数

dirname(i) 各階層のディレトリ名
dirban(i) 何番目に上のディレクトリが見つかるか
file(k) 現在調べているディレクトリでのファイル情報( 名前、サイズなと゛)

filesyori () {
path = dirname(0) +・・・+dirname(m)を開く
k=0;
if ( file(k)がファイル)

さて、進んでいるかい？

ファイル検索のDLLは作るから、GUI部分を作ってくれ。

まかせろ

誰もいなくなった？
UnDup にデータベース機能がついた様なソフトが
理想形となってるみたいですね。デスカ？

俺が使ってるのは多分ファイルサイズくらいしか見てないと思うが、そんな死ぬほど遅いわけじゃないけどな
同サイズのファイルが大量にあると若干遅くなるけど

>>79
それ考えたけど、データベース作成後に
ファイルが更新されているかどうかを調べるのが困難。
HDDだと書き換えられるから、全体を再チェックしなくてはいけなくなる。
それにデータベース作成時間程度かかる気がする。

データベースをチェックしないままだと重複ではないものを、重複と間違えることが出てくるけどこれは大したことでは無い。
しかし、重複であるものを、重複とみなさないケースが出てきてこれを見つけるのが困難になる。
結局、全部検索することになりそう。　

てか、そもそも何故DBを使うの？
重複検出を一回やるだけなら全部オンメモリで処理しても足りると思うんだけど。

後で別の重複検出をやるときにDBに入れたデータを再利用するってことなのかな？
そうそう再利用できるケースがあるとも思えないけど…そんな同じファイルを何回もHDD上に生成したりするものだろうか？

ファイルのハッシュ値と詳細を記録するとかだったらまだわかるんだが。

DVDとCDは書き換え不能とし、それだけデータベース化するなら簡単だけどね。

>>83
おもな利用方法はCD、DVDとの比較と思います。データベース導入ならHDDもしないと不自然だなと思うわけです。

UNDUPを超えるソフト作ってシェアウェアにすると幾らくらい売れますか?
500円として100個は売れますか?

UNDUPで十分なので売れません

UNICODEや長いファイル名に対応していなくて、落ちやすいバグがありますよ
あとデータベース機能機能もつけて、UNDUPの速度を半分以下にしたら幾らくらいですか?

シェアウェアにするなら最低でも1000円にしておけ。
500円でも1000円でも売り上げ本数は変わらんだろう。売れるかどうかは別問題だが。

速度を半分以下にするのか。遅いな。

シェアウェアで小ヒットするといくら位なんですか?　

あー、昔作ったことあったわ

シェアウェアにするほどの価値はあるのか？
どうでもいいのに金払うのが面倒だろ

優秀な最大公約数的なソフトがフリーであるのに、
わざわざ得体の知れないシェアを使おうとは思わないな。

それに使うとしても月に一回ぐらいだろ?

UNDUP　(600円)　に対抗して、使用制限無しで500円の販売したらいくつ位売れるのかと
思ったんです。大して売れなくても良いんですけど、
UNDUPを完全に上回ったとしたらどの位かなとおもったんです。

自分でそういうソフトを選ぶ基準から考えてみろ。
UNDUPがあるんだし、他の、しかもシェアウェアを
わざわざ選ぶ理由なんてあるか？ゼロだろ。
買われるとしたら、検索もできないネット覚えたての
情報弱者がたまたま最初にみつけて、間違えて買うぐらいだな。
今時小学生でもありえないが。
UNDUP程度なら誰でも作れるんだし、ここでぐだぐだ
売れるかどうか、なんて書いてる奴のソフト、しかも
猿真似のシェアウェアが売れると思うか？
この程度のソフトなんて作っても金にならんぞ。
オクで転売でも始めた方が儲かるんじゃないか？

完全フリーにして名前売った方が後々儲かるかも。

空気読まずに書くよ

全ファイルのMD5とかSHAハッシュ取ってsortコマンド使えばええやん
殆ど重複はしないでしょ

でかいファイルは4MBくらいで読むの止めて、サイズ一緒に出力しておけばいいし

>>98
小学生は大人になってから来てね

データの比較方法はわからんが>>1が言うのはこういうのか？
ttp://www.vector.co.jp/soft/win95/util/se373076.html

容貌

画像MD5比較で条件付削除ができるようにして

>>101
どんな面しているんだか。

どういう意味かと思ったら、容貌から来てるのね。

今から作るなら画像／音声／動画の類似性をチェックするぐらいの意気込みでお願いしたい。

こんなんで用が足りてますが何か

find /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;
}
}
}

sage

UNDUPおせえｗ
Win32API使ってる時点でこれが限界か

しかし>>1の着眼点面白すぎだな
2^24個のファイルってMFTが16Gになるぞ
その上ファイルサイズは4G制限かｗ
てかたった1年前の話なのにCRC16とか出ててフイタｗ
5年位前のカキコかと思ったわ

ほしゅ

ハッシュとファイル名をペアにしたキャッシュは取ってんの？
大方>>1の見え透いた用途では、古いファイルが変更される事は
少ないんじゃないか？だったら

キャッシュ.txt:
最終更新年月日
MD5等ハッシュ　ファイルパス
MD5等ハッシュ　ファイルパス
MD5等ハッシュ　ファイルパス
　　　　　　　　・
　　　　　　　　・
　　　　　　　　・

とファイルをフォルダごとに作っておいて、比較対象は最終更新年月日より
タイムスタンプが新しいものに限ると。これだけで>>1の様な用途なら十分
高速に使えると思うぞ。

見え透かせるって事は同類か

ttp://www.vector.co.jp/soft/winnt/util/se454495.html
これはどう？

複数のDVDにバックアップしたデータをまとめてブルーレイに焼きたいのです
でもかぶってるファイルが多数あるのでそれらをまとめてから焼きたいのですが
どうすればいいですか？

板違い

>>113
ファイルの重複検出ツールのスレですよね？

>>114
で、お前はどういう方針でツールを作ろうとしてるの？

ってか、システムにファイルを通す際に必ず同じプロセスを通過するようにすればいいんじゃないかなあ。

ファイルコピー→＜ファイルチェックプロセス＞→ディスク
って感じで。
ファイルサイズとかハッシュが同じファイルを通そうとしたら弾くとか。

>>116
馬鹿発見

>>114
重複検出ツールを「作ろう」ってスレだろ、ＪＫ

>>118
その成果だけ頂きたいのです、女子高

そういうやつはこっちだ
http://pc11.2ch.net/test/read.cgi/software/1145546190/

>>119
未成熟ぎみなのがいいんです、JC

数十万個のファイルの中から指定のファイルとほぼ同じ内容のファイルを高速に検索する
方法はないでしょか？

完全一致のファイルならファイル名と MD5 のデータベースを作っておけばファイル数に
関係ない時間で検索できるのですが。

>>122
ある通信プロトコルでの相手を決定するための方法だけど、
その数十万個分のファイルに対応するオブジェクトを作る。
指定のファイルのオブジェクトのビット(特徴)を、1こずつそれらに送る。
同じビット(特徴が一致した)なら応答を返す。
応答が最も多かったファイルを「ほぼ同じ内容」と判断する。
ようするに、比較をインクリメンタルにやるという話。
ハードウェアでの通信だと一瞬で判定できる。
それをソフトウェアでやると個数分の時間が掛かる。
まあ総当りするよりは速い。

ファイルの一部のMD5つくれば? とる位置を3カ所くらいにして、それが一つでも一致すれば疑わしいとする。
あとは人間が確認する。

どうせ、画像ファイルだろ。MD5を作るんじゃなくて、サムネイル画像作ってそいつで比較したら?w

画像なら、画像の特徴を比較する必要有り。部分md5では無理

サムネイルもインデックスみたいなもんだな

最近のコンピュータは高速だからファイルの先頭から1ビットずつ比較しようぜ

指紋認証のやり方で特徴点抽出

122 ですが、ファイルは主にプログラムのソースコードです。

現在使っている MD5 以外の検索方法は
ベースファイル名が一致しファイルサイズが近いものを DB から抽出し、
ファイルの最初の 128KB のバイナリ差分が小さいものに絞り込み、最後に
ファイル全体のバイナリ差分が小さいもの選んでいます。

この方法でそこそこの時間で検索できますが、大幅な絞り込みのために
ファイル名を使っているのでファイル名が全然違うファイルは検索対象に
ならないので困っています。

先頭32K(違いが出なかった場合は32K-64K、64-96Kなど)
のMD5を保持しておけよ。

ハッシュじゃ類似判定できないだろ

ベクトル空間法 類似
でぐぐれ

>>130
ソースコードならクラス、メソッド名だけ抽出して比較すりゃ終わりじゃね？
もっと確度上げたいなら変数名も追加

バージョン違いのさはどうするんだ

調子のんなよカス

>>135
お前の恥ずかしさに免じて何も指摘しないでやる

クラス名などが一致しても、コードの中身がバージョンのズレにより
大きく代わることがあるだろ。

初めから書き直したりした場合だ。

>>138
お前なぁ、自分で墓穴掘ってちゃ世話無いだろうが
もう分かったから、そのまま墓穴に埋まっててくれ

Mr.Driller 好きだぜ

ゆ○ぽのことか？

中に特定の文字列がある穴を探して埋まっておけばいいんじゃね

ソースコードだったら大体同じようなクラス名や関数名で書いてるだろ
分かりにくいコード書いてるやつがいたら穴掘って埋めればおｋ

undupとかの重複ファイル検索ソフトの比較スレがあったと思ったんですが、見つかりません。
どなたかご存じないですか？

お勧めの重複・類似・近似画像処理ソフト2
http://pc11.2ch.net/test/read.cgi/software/1145546190/

つくりましたよ。
・ファイルリスト出力ツール＝フォルダ内のファイルをリスト化。テキストにMD5付きで出力(ファイル名、ファイルサイズ、MD5) DVDに焼く前の汎用ファイルリストとしても使えるかな。
・チェックツール 上記ツールで作ったテキストをDBとして、フォルダ内のファイルを順にMD5出して、もしDB内にあるファイルがあれば自動削除

これで一旦リスト化すれば、ファイルはDVDとかに移動しても、リストだけで比較・重複ファイル削除できるからパソコンに同じファイルがある必要もない。
重複チェックツールは数あれど、DB化したファイルから検索するのは少ないし、ややこしい操作多いし、自分でつくりました。

速度はHDDのリード速度に比例する。毎秒100MB/sくらいかな。1GB10秒 60GBのフォルダなら10分＜＜ファイル全体のチェックのシステム上、これ以上は速くならないから勘弁。

MD5をすべて計算するのは初心者。
先頭5K、10Kも比較すればほぼ判定できる。
すべてのデータのハッシュを計算するのはよくあるが鈍すぎる。
5Kで異なればすでに異なることが判定できている。

ほぼ判定より、全判定したほうが確実だろ。
独自解析形式にしたら、そもそも汎用性がなくなる
既存のツールのMD5表示と同じものがリスト化されるのが有意義なのに。

速度も最近のHDDなら結構はやい。25GBでリスト化2分程度。
そもそも、これはDVDとかに焼いてもうパソコンに無いファイルとの比較を誤差なく重複検知する
のが主眼なので、一旦リスト化されたものを検索するだけだから、リスト化さえすれば非常に高速。<<テキスト見てるだけなので
最近追加されたファイルだけをMD5するだけだから、時間はそんなにかからん。

あとあとのことを考えれば独自形式にするほうがめんどい。

MD5もほぼ判定だが　ハッシュだろ　衝突することはある

とくに最近は
公称1GB/sの超高速PCIe-SSDが発売
http://www.watch.impress.co.jp/akiba/hotline/20090530/etc_pfast2.html
こんなのも出てるから、新規追加分だけMD5化する時間なんて誤差の範疇。

こういうのが一般化する将来のことも考えて、汎用MD5値をリスト化するほうがいい。
あとあとこの先何年も自分が使うリストだからな。

>>149
クラッキングとかじゃなしに、普通のファイル検索でMD5一致って何分の1の確率ですか？
そんなに頻繁に衝突するようなら、ファイルサイズとMD5が完全一致した場合のみ重複と判定
ともできますが、ファイルのMD5はよく一致するものでしょうか？

16^32＝の確率でたしかに偶然に一致しますが、ちょっと天文学的な確率なので。(1/3.40282E+38 分の1の確率？)

どうせならSHA256、512にしとけ
あと、いかに早く検索できるかが大事
60GHDDのサーチに10分もかかるのはだめだね

MD5の一致確率は、先頭10Kのみより多いだろうな。　
テキストファイルで、後半だけ変更したりすると検出できない確率はあるが。
そういうやつは特別に扱って別の位置も取得しておけばいい。

とりあえず未熟ななりに作ったものをアップしたいんですが、どこがいいですか？

短縮化として、ファイルサイズでとりあえず一致したものだけMD5でも
さらにチェック

とすれば、数百倍の速度になると思います。怪しいものだけチェックすれば、それ以外はMD5チェックいらないし。
ファイルサイズ違えば違うファイルだし。「類似」がどうのは自分には難しいので自分はパスします。

>>154
UNDUPしかない感じだからいいやつ頼む。

>>151
確率はかなり低いだろうが、鈍いことが問題。
1000万ファイルもあれば一つくらいは衝突するのでは

1/3.40282E+38(0が38個ね) 分の1の確率だから
3百澗分の1。 1000万ファイルすでにもってても、それに一致は百穣分の1
ゼロではないが、気にしてもしょうがねー数字。というか何分の1かぴんとこないな。
http://ja.wikipedia.org/wiki/%E4%B8%87%E9%80%B2#.E5.A4.A7.E6.95.B0

あと高速化も兼ねてるファイルサイズ一致兼、MD5一致なら、これよりさらに100万分の1とかの確率

>>158
初心者乙。
もっともいい分布でハッシュが作れたとしても、そんなに低くない。
たとえば、5個のうち3つ選んで重複しない確率は、1/5ではない。
1/2^128 というのは、2つだけハッシュを生成して衝突しない確率。
1000万個すでにハッシュが生成していたらそれにかぶらない数字でなければいけない。

Kがデータの総数とし、p(n)はn+1個目までに少なくとも一つは衝突する確率とすると
p(1)=1/K
p(2)=p(1) + (1 - p(1)) * 2/K
・・・
一般に
p(n+1)　=　p(n) + (1 - p(n)) * (n+1)/K
という式で表される確率だろう。
解き方はしらんが。

>>159 1000万個すでにハッシュが生成していたらそれにかぶらない数字でなければいけない
だから1000万ハッシュがある場合は、10^7減って 1/3.40282E+31 3百穣分の1になるんだろ。

たしかに3百澗分の1より3百穣分の1のほうが数字的にはかなり確率が高くなるが、
そんな単位にそもそも何の意味があるのか理解できません。

「百穣分の1なんて多すぎる！」と気にする人はMD5一致兼、SHA1一致兼、SHA256兼、SHA512一致の多重チェックで
好きなだけ確率を追い求めればいいと思います。

それより、関連して困ってた件で、

雑多な階層のZIPファイルの重複検知がてこずってましたが
＞＞サイズが中間フォルダのせいでか、微妙に違い
MD5も違ってくるから、「違うファイル」とされる。(同じ画像フォルダなのに)
これをなんとかするには、「解凍+後始末α」とかでZIPファイルを解凍しつつ
一層化して、再度無圧縮ZIPにする
これでMD5が完全一致するから、重複削除可能。
(名前によらずMD5値だけで削除できる)
無駄なテキストや、htmlの削除で無圧縮ZIP化する前に不要ファイルを削除して共通化も必要
これにはFcleanが便利。

>>161
初心者乙。　1000万個目までに一回でも衝突が起こっていたらだめ。
うまく1000万個目が衝突しなくても、それまでに衝突が起こっている事はある。

>>162
ファイルの中身のデータを取得して比較しよう。
サイズや日時や名前が使える。CRCもあったような気はする。

>>163
だから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倍以上時間かかるし、効果もよく分からんので。 どうしてもやれといわれれば、作りますが。

それは1000万回目だけ衝突するかどうかの確率だろが
初心者は無視した方がいいのかな・・・

自分で煽っておいて何言ってんだか

めんどくさいなー計算させるなよ。


サイコロ 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の確率です。

逆に出ない確率は サイコロの数値を順に登録していく場合
最初＝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つも重複しないパーセンテージでの確率です。

あたまが弱いだろ。　1000万個目以降の確率求めたってだめだろ。　
MD5のハッシュが一致しないって言うのは、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

一度も、一致しない確率を求めた方が簡単だな。
たとえば
さいころを5回振って一致しない確率 = 6*5*4*3*2 / 6^5　= 0.9074

N = 2^128 、M =1000万とおいたとき

MD5が一度も一致しない確率は、　N(N-1)・・・(N-M+1)/N^M　だな。

誕生日のパラドックスでぐぐれで済む話を何を延々と

http://d.hatena.ne.jp/yappo/20090122/1232597488
sha1 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以上にするととろいんですよ。

先頭のCRCで十分。　一致してから後半を読みに行けよ。
全部生成したら、主にディスクアクセス速度に依存する。

MD5やSHAは暗号化のためであって、
ハッシュの分布頻度を均一にしようとしていないだろ。
ビットあたりの無駄のなさをはかればCRCが飛び抜けてるんでは。
CRCは32が有名だが、64でも128でも出来る。

＞MD5やSHAは暗号化のためであって、
＞ハッシュの分布頻度を均一にしようとしていないだろ。
初耳、ソースplz

しらんが少なくともCRCは暗号ハッシュではない。


CRCは誤り検出符号の一種である。
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

CRCの事じゃなくて>>176の上の２行の根拠を訊きたいんだけど？

もう今はSSDあるんだから、速度ほしければリード250MB/s出るSSD買えよ。
SHA1は10MBのファイルでQ6600で60sかかるから無理ぽ。
1000Mのファイル1個のSHA1値出すのにまるまる100分間？

強度がどうこう以前に選択肢にもならん。

http://www.emit.jp/sha/sha.html

SHA1は10MBが1秒以内

http://hp.vector.co.jp/authors/VA033110/fasthash.htm

これも一秒以内　
10Mでは比較が出来ん

200Mで比べたら数秒だけ182の方が速かった。気になるほどの差はない。
ディスクをいいタイミングで読み込めたかどうかだけと思う。=ディスクアクセスの差と思う。

変な独自形式のSHAのプログラムの場合だった。

24.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ですかね。

crc256mmx

http://www.volny.cz/lk77/crc256mmx/index.htm

SHA1とSHA2の計算方法はほぼ同じ　速度は変わらない


1993年にはじめに発表されたものは、公式には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

自分が読み間違えた。 SHA2の中身はどれもにているが正解。

分布が均等であるアルゴリズムであることが大事。　
たとえば、32bit取り出してみて、CRCと衝突回数比較してみるなど。

あのさ、ハッシュ関数ってのは十分に分布が均等なの
違うって言うならその根拠を示してみろ

>>179
もともとが暗号の為のもの。wikipediaでもみろよ。
ハッシュの散らばり具合は、ある程度はいいだろうけど、
同一ハッシュが生成されないようにすることの方が大事。

>>189
実験してみればわかる。　
いまの場合だと、同一ハッシュが求めらない耐久さより、
衝突が起こりにくいことが大事。

ここで使うハッシュは衝突が起こりにくければそれでいい。
たとえば、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]でもいい。衝突が起こらないければいい。

>>190
そのWikipediaにハッシュ関数とはハッシュに値上の偏りが無いことが要件の一つって書いてあるけど
>>176の２行目はそれを否定してる、その理由を訊いてるんだけど？

暗号ハッシュと、
偏りが出ないことだけを追求したハッシュの違い。

>>194
偏りがでなければそれはすなわち暗号ハッシュに使えるのでは？
偏りがあったら、暗号ハッシュとして攻撃されやすく脆弱性がある欠陥品だろ。

>>194
CRCに比べればって話か
なら分布頻度を均一しようとしていないってのは言いすぎだろ

衝突が起こりにくいことと、同一ハッシュが生成できることは別問題。
(暗号も通常も)　ハッシュとして衝突が起こりにくいことはまず必要。
あるハッシュ道が与えられたとき、
計算で一致するデータが求められるかは、上の衝突とはあまり関係がない。

たとえば、x & 255 というのをハッシュ関数にして、
0から255が一回ずつ現れれば、衝突は一度も起こらない。
しかし、ハッシュ値　1と一致するするデータほ生成することは容易。
257　& 255 = 1

>>194
そもそも「暗号ハッシュ」という括りが一般には存在しないのでは？

ハッシュ（切り刻む・滅茶苦茶にする）は、大きなデータから
一方向性と非衝突性を"なるべく"満たすような小さなデータを
作り出す操作を指す。

確かに、その主なアプリケーションは、デジタル署名や共通鍵(TKIP)
の生成だが、それはハッシュ値が
　・元データが違えばだいたい違う値になる
　・ハッシュ値から元データを類推するのが難しい
という性質を利用した物で、そのためにハッシュがあるわけではない。

ファイルが、"多分同じ"で有ることを確認するためにも使われるし、
大きなデータを扱って、100.00% が求められない データベースの
インデックスとしても使われる。

MD5、および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 より

SHA-3 - Wikipedia

SHA-3（Secure Hash Algorithm 3）は、NISTが公募中の新しいハッシュ関数アルゴリズムである。
現在は公募されたハッシュ関数が公開され、これから評価を行うフェイズにある。

ハッシュ関数としてはSHA-1が米国標準となっていたが、ハッシュ関数攻撃手法の発展とともに、
SHA-1の衝突発見の可能性が現実的なものとなったため、NISTはSHA-1に替わるハッシュ関数の公募を行うことを決定した。
SHA-1のブロック長は160ビットであるが、誕生日攻撃に必要な計算量をAESの全数探索計算量と同じくするため、
ブロック長は256ビット以上となると考えられる。

>>200-201
それは強衝突耐性の話

なんか潔癖症のやつがいるな。
重複検知は、理論上、誤検知確率が潔癖症が好きな「ゼロ」にはなりえないから
そんなに病的に気にするやつは重複検知なんかするな、全部まとめて保存しろ。
それなら間違って削除することもないだろうよ。

まとめると暗号強度と、衝突にはあまり関係がないってこと。
128bit中、上位120bitが常に0だったりすれば、暗号強度も弱いし、衝突も起こりやすいが
そういう間抜けな関数でない限り、
暗号強度が高くても、衝突は起こるし
逆に衝突が起こらなくても、暗号強度は低いことはある。

「天文学的」な巨大数
http://ja.wikipedia.org/wiki/%E5%B7%A8%E5%A4%A7%E6%95%B0

宇宙の原子の数は10^81個 SHA512は10^154
Googleという名前が、実はとある数字と関係するって知ってました？ ＝グーゴル - 10^100

128bitのハッシュに偏りが無いと仮定して
1億の内容の異なるファイルの中に同値のハッシュが存在する確率は
0.00000000000000000000147パーぐらい(多分)

>>204 まとめると暗号強度と、衝突にはあまり関係がないってこと。

勝手に変な結論をださないでくれ。
>暗号強度が高くても、衝突は起こるし
暗号強度が高ければ衝突は起こりにくい。
暗号強度が低ければ衝突が起こりやすい。
例外はない。 わけのわからない結論を出さないでくれ。

http://slashdot.jp/comments.pl?sid=203703&threshold=-1&commentsort=4&mode=flat&cid=607097

こういうのを見るとブロック化は問題ですね。やっぱファイル全体のMD5で検知しないと。

CRCは何ビットのやつでも、簡単に同一ハッシュ見つかるが
分布はなかなか良い。(衝突は起こりにくい)

CRCは簡単に言えば、割り算のあまりを求めるだけだから
たとえば、x%100　という関数と暗号強度は変わりはない。
この場合、ハッシュ値10と一致するのは、100n + 10 と一般項が求められる。

そもそもみんな何がしたいの？
暗号の話じゃなくて、ツールの話でしょ。

いちばん確実なハッシュは、zipやrar。　元のデータさえ復元できる。

今パソコンにある重複ファイルの削除なら
「重複確認」が便利だな。
これにDVDとかにあるファイルのMD5も参考に削除できればいいのに。

MD5,SHA1の出力だけならFastHashが便利SHA512もCRC32も選択できるし高速
だが「重複確認」とFastHashの両方の機能を合わせたのがない。

FastHashでファイルを出力して、それを参考に
削除もできるね。比較モード

これでいいかもな。このスレ終了？

python の filecmp.cmp はでかいファイルでも結構あっさり判定するな。
どういうアルゴリズムなのかは知らないが。

サイズ判定して、一致したら、32kをランダムに5個ほど抜き出せば良い

>>217 サイズ判定して、一致したら、

こんだけのことが結構難しくて苦慮中・・・

フォルダ読み込んで、pathとサイズをSTL setにぶち込めばサイズ順なる。

もう少しかも・・ ファイルサイズ簡易チェックでパスしたものだけ
＝怪しいものだけをさらにMD5チェックかけるんだな。
ファイルサイズも同じで、MD5でも同じなら天文学的確率でファイルが同じなので削除と。

おれも作ってみる！

フォルダ内重複削除(ファイルサイズ＞MD5の多重チェック) はできた。
高速化できてかつ、通常のMD5の1億倍以上の精度にはなったはず。一石二鳥？

次は既存リストとの照合か。

普段はPythonな俺がC++で気合入れて作ったけど、結局ネックがMD5の箇所だから大して速度変わらんわｗ

全MD5を計算するなよ
どうせハッシュ(間違いはある)
前後と真ん中の3カ所くらいだけ抜き取れば十分
4GのISOとか読み込みのはだめだろ

完全一致が調べたいのなら、すべて比較するしかない。　
MD5ではまれに間違える。　
重複候補をリストアップして、あとは手動か、完全比較を選ばせばいい。
全ハッシュでは、4G以上のファイルがあれば、いくら高速化しても無駄になる。　

やっとできたー。変なループエラー潰しで疲れた。
肝心の速度だが、
ファイル数10508 総容量265GBのフォルダの重複一括削除で
MD5版
4分19秒
SHA1版
8分47秒

リスト内検知も高速で、サイズ一致がない場合(MD5検査に入らない場合)
ファイル数10508検査が2秒で完了 基本的にサイズが一致しない限り、MD5検査とかしないからかなり高速。

リスト内のサイズと一致した場合 MD5する必要があるが、これはHDD読み出し速度程度の所要時間。
↑の場合以上にかかることはほぼないはず。(このフォルダ例は相当の重複(1割以上)が多数フォルダにあるやつなので)

こんなもんでいいですか？ HPでアップします。

おつ　URLはないの?

http://homepage3.nifty.com/d38pvz/
こんな感じで。一応変な挙動がないか確認しましたが、
やばい問題がありましたら、再現状況を添えてメールしてください。

汚いソースですいません。

>>228
まだ実際に試してないんだけど、これって最初に全ファイルのハッシュリストを作成するの？
もしそうなら、比較するときもリスト内のハッシュ同士の比較で良くない？

Rubyでwindows使いなら、exe化、GUIたのむ

>>229
DVD等に焼くファイルのリスト化は、最大限の情報抽出が必要なので
全ファイルのMD5値を出します。

手元にあるファイルのフォルダ内重複確認・リストと照らし合わせての重複確認
はサイズ一致を先に調べ、それで一致した場合、MD5値を調べます。
最初はフォルダ内の全ファイルのMD5をすべて出して比較してましたが、それだとファイルサイズが違う＝明らかに別のファイル
までMD5を出すのは無駄な作業なので。

問題はRARとかで1000 000 000(1000M)とかでバイト単位まで決めて分割圧縮してある場合ですね。
これだと大量に1000 000 000 バイトのファイルがあるので、ファイルサイズ一致で省くことができず、全部MD5を出す過程が必要です。
この対策はあんまりないので、一度解凍して無圧縮で1つのファイルに圧縮かけてもらうしかないですね。それか圧縮しないで個別のファイルにして保存とか。

どうせハッシュだといってるだろが。
前32K中32K後32Kを抜き出してつなげて、ハッシュ計算しろよ
速いぞ

先頭10Kとサイズだけで一致することはないと思うが、中と後ろは念のため。

>>231
なるほど。DVDに移したファイルをHDDから削除するためのツールってことね。
DVDなんて使ったことないからそんな用途思いつかんかったｗ

こんな3日仕事おまえら何年掛かってんだよ

おお
3日後を楽しみにしてます

>>232
ソースあるので、修正ヨロ
もしくはブロックハッシュ出す方法(perl)の参考HPを教えてくれ(探したが全部出す方法しか分からんかった。)

つ
http://www.geocities.jp/ky_webid/perl5/018.html
http://www.site-cooler.com/kwl/perl/7.htm

サンクス、暇できたらこれ使ってさらに高速化してみるよ。

>>228
補足とか言ってマヌケな計算式のままかよ
こんな繰り返し指摘してもらってるのに理解できなかったのか？
確立計算も出来ない馬鹿が作る削除ツールとか何の罰ゲーム

貴方のような子を持った親の方が罰ゲームだと思われます。

確立ｗ

>>240
なにが問題なんだ?
なんだか分からん桁数のファイル数を扱った場合に発生する天文学的な衝突可能性を気にするなら､
MD5じゃなくてクソみたいに時間がかかるSHA-512で処理すりゃいいじゃん｡

何をどうやっても衝突確率は天文学の領域なんだし､何が問題か理解できんが｡

つうかSHA-1で｢偶然2つのファイルのハッシュが一致｣したら､世界的なニュースになるわ｡
同じSHA-1で､完全に別ファイルかつ壊れてないファイルの発見って､人類が宇宙人と遭遇する確率並だから｡

問題はフォルダの重複一致だな｡
名前が全然違うが､中身は一緒ってのをどうやって検知するか･･･
zip圧縮のzipファイル検知って､微妙にMD5が変わるし｡
中に変なテキストファイルが1個入っただけで｢違う｣となるし｡

AフォルダのA〜Zファイルを全部持ってるBフォルダがあるとき､Aフォルダは削除していいんじゃないかと｡
｢大は小を兼ねる｣判定で｡
もしくはBフォルダ内のAフォルダのA〜Zファイルを削除するのかな｡｢小フォルダを優先｣
(この場合､総集編みたいなフォルダを減らせる)

ややこしいな｡

全ファイルにシーケンシャルアクセス！

厳密に重複確率を誕生日問題までも考慮に入れて計算できた｡
http://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兆個もってない場合､これを遙かに下回る遭遇確率となる｡

で､これよりバイトチェックもしてるから､128bit以上の強度にしてます｡
まずサイズ同一でないのはすべて弾く｡
で､サイズ一緒でかつ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版もありますが､これを遙かに数十桁上回ります｡

誕生日問題を考慮してもこれくらいの確率に収まりますね｡

1000兆分の1〜10京分の1すら気にするようならSHA1をどうぞ｡
まあMD5でもありえない数だが｡<<MD5の一致確率を気にするようなら､
宝くじの当選確率300万分の1なんてあほみたいに｢当たる｣日常的なものなので､
急いで宝くじ売り場に行くことを進める｡


↑そもそもこの前提条件の｢ファイル数所持1兆個｣を達成するのが非常に難しいんだが･･
100キロバイトのファイルを1兆個だと･･･
Gの上のテラの上のペタ､ 100ペタバイトのHDDが必要｡大変ですね｡

９ヶ月前のレスにマジレスするのもどうかと

それより似た画像を探すツール作ってよ

Amara Ranipas の画像を自動収集するツールを作ってください

CheckOverlap
http://space.geocities.jp/checkoverlap/

これはいいと思う

FileMany
http://codepanic.itigo.jp/FileMany.html

今パソコン上にあるファイルの重複チェックなんて作るまでもない。
｢もうないファイル｣の重複チェックツールがないんだが。

ファイル情報を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が違うことは(編集操作してない限り)そうはない。

ただ、画像ファイルでMD5つくると、かなり膨大なファイル数になるので
MD5では厳しいかと思う。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化する合理的な理由がないんだが・・

>>253
できたんですね。これはいいツールだと思う。
自分用にリストをカスタマイズできればもっといいが。
あとアルゴリズムだが、サイズチェックはどうしてるのかな？

自分はまずサイズでチェック(同一フォルダとハッシュリスト＝サイズも記載)
で、サイズ一致してからハッシュ合一性調査するな

たとえば10GBのファイルがあるとして、この方法だと(サイズがバイト単位で完全一致しない限り)
この巨大ファイルのハッシュを出すまでもない・・

って同じことか。次回にいかすためにはMD5ださないと削除できないので、リスト化をしてるならそれでいいのか。
なるべくファイルサイズあるなら、ファイルサイズかつMD5両方チェックできればいいが、趣味の問題なので(MD5はそれだけで信用に足るとしていい)

まあよく考えられたツールだと思う。がんばりましたね。広まるといいですね。
クソファイルリスト＝ハッシュリスト をダウンすればクソファイル検知もできるわけで、

｢ハッシュ化したのをリスト保存して次回検索に使う｣
はありそうでなかったのでこれが広まるといい。

|2042|632043928600000000|

これがなんななのか分からんが・・

■終了時に作成済みハッシュ情報をリフレッシュ（ONを推奨）
作成されたハッシュは
・ハッシュ
・絶対パス付きファイル名
・サイズ
・最終更新日時
の４つが１セットで記憶されており
従ってファイルが移動されると、記憶しているハッシュ情報が次回使えなくなります。
このような古い情報を削除（リフレッシュ）するためのチェックです

？？？ どういうことだろうか。その場限りのリストっすか？ だめじゃん。

>>256
流れはサイズチェック　→　サイズ一致してるもののハッシュチェック　→　ハッシュ一致してるもののバイナリチェック
です。サイズチェックはプログレスを未表示です。ごく短時間で終わるので
設定によって省略されるものもあります

>>257
ハッシュ情報のリフレッシュの意味ですが
ファイルが更新されたら作ったハッシュが古くなりますし
フルパスのファイル名をキーにして記憶しているので
そのパスにファイルが存在しないなどの場合、記憶したハッシュをクリアしています。
なので、基本的に作られたハッシュは覚え続けて次回以降の検索に活かされます

hash.txtの内容は↓
ハッシュ値｜サイズ｜更新日時のTicks｜フルパスのファイル名

インターフェースの話だが、
ハッシュリスト使って重複検知するなら、
上のタブとかに｢ .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

マイクロソフト謹製のファイルのハッシュリスト化＝サブフォルダも一括 アプリ
http://support.microsoft.com/kb/841290/ja
SHA1リスト出力＋SHA1でファイル比較可能。
結構使えるし、組み込もうと思ったが
ファイル名完全一致してることを前提に動作するので、微妙だな。

ファイル名が違ったら違うファイル扱い？ ハッシュわざわざ出す意味ないじゃん。
KBのファイルの検査用にしか使えんな。

MD5(sha1)ハッシュリストを出すというだけであれば
c:\tesフォルダ内のファイル
パスなし
fciv c:\tes -wp >list.txt
パスあり
fciv c:\tes >list.txt

c:\tesフォルダのサブフォルダも一括して
fciv c:\tes -r >list.txt
で出来る。このリスト使って重複比較すればいいかな。
｢リスト作成ツール｣はもうMSさんが作ってましたと。SHA1もできると。
あとは比較するだけと。

類似画像検索
http://www.geocities.jp/the13lackart/GRID.html
これはいいソフトですね。
http://www.my-standard.co.jp/1797.html
スピードも速いらしい

設定保存つくったんですね。すごいですね。やりますね。
今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に書いた方がいい。先頭ハッシュ計算だと強度はそれなりに下がる。
暇会ったら計算したらいい。

FileManyやっぱり動作が分からん・・
ハッシュどこで使ってるんだ？
Aフォルダ読み込んで検索でハッシュ作成 終了＝ハッシュリストができる。
Bフォルダ読み込んで検索

A＝Bなんだが(A,Bフォルダ内部では重複してないが、｢さっき検索したAフォルダ｣と同じファイルが入ってる)
で｢重複なし!｣となる。

ハッシュリスト何につかってんだ？ ただのログ？ それで検索はできんのか？
それじゃそこらの重複ソフトと同じだし・・

あと重複ツールって最後の削除時に全部ごっちゃにしてかき混ぜるよね。
重要フォルダ＝削除したくない 新フォルダ＝削除したい なのも構わずごっちゃごちゃにかき混ぜて削除する。


で、｢重要フォルダ＝削除したくない｣のファイルが消失するんだな。1つずつチェックすればいい？
6万ファイル重複してるのを1ファイルずつチェックとか死ねるわw そんだけで5年かかる。

保護フォルダの概念がないってどういうことかな？ ＜＜そういう意味合いもあって｢削除したくないorできない(既にDVDに焼き済みで手元にない)フォルダ｣のリスト化したいんだが、
なんだか分からない論理でファイルの順序を最後にごちゃごちゃにして重要フォルダを｢破壊｣するから怖いよな。

また自分でつくるかな。

D:\A>tes.pl
↓----------------↓
リスト内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リストを作って、そのリストを｢指定｣して比較して、重複を削除できると
＜＜つまり削除するのは完全に今のカレントフォルダ(＝正体不明の最近のフォルダ)以下のファイルのみ削除
保護フォルダの概念がある。

リストにはサイズも入れた方がいいかな。
ファイルサイズ MD5
ファイルサイズ MD5
ファイルサイズ MD5

のリストを作って、それで比較と。MD5以上のセキュリティ強度かつ高速化できるな。
ファイル名とか更新日とかは｢信頼に足りない｣ので無視、リストが500万ファイルとか膨大になるとこうした情報のサイズもバカにならない。

>264
設定に従い対象フォルダ以下の全ファイルを列挙
サイズが一致するものをリスト化
同じサイズのものをハッシュ比較
ハッシュも同じものをバイナリ比較
ハッシュ作るまでもないものまで毎回作るって無駄だろ
ハッシュできない＝作る必要ないってこった

保護フォルダっつーかフォルダ選ぶの自分だし
破壊ってなによｗ
数万個も一致するような状況で使うツールじゃない
しかも１回使ってHDD掃除したら当分動かさなくていいジャンルのソフトだろ？
264には期待してるよ。すげーの作ってくれ

http://codepanic.itigo.jp/FileMany.html
に書いてあった

４．検索が開始されます

参考：アルゴリズム
a．検索対象ファイルを全て列挙
b．ファイルサイズの昇順にSort
c．同じサイズのファイルが２つ以上ないものは候補より除外
d．サイズが一致するものを重複ファイル候補とします
e．ハッシュ比較がONであればさらにハッシュで比較を行います
（この時、既にハッシュ作成済みデータがあればそれとの比較）
f．１バイト単位で完全一致比較がONであれば全データをバイナリ比較（※１）

>HDD掃除したら
焼いたファイルも｢掃除｣の一種
DVD等に焼いて手元にないファイルも｢パソコン内｣と見なす重複検知ツールが市中にないってこと。
焼かないやつでも外付けHDDに入れたのとかあるでしょ。HDDいちいち全部つけるの？

>>269
やっぱそれじゃぐちゃぐちゃになるよね。ファイルサイズでソートしちゃうんだ？
それをまた並べてもフォルダがごっちゃになるわな。｢可能性｣があるだけでも怖い。
たとえばちゃんと整理して綺麗にしたフォルダがある。新しいフォルダ(最近ネットで落としたのとか)がある。

それで｢整理したフォルダ｣と｢新しいフォルダ｣を重複検知したら整理フォルダのファイルまで破壊されたんだが・・
また整理しろと？ どこに何があるかも分からないのに、

あと歯抜けフォルダが大量にできたりとか・・
バカじゃねーの・・ 整理されてないフォルダに対して重複検知するんだから、フォルダ名・階層が綺麗とは限らん。
そこらへんのとこも考えて欲しいな。

>｢整理したフォルダ｣と｢新しいフォルダ｣を重複検知したら整理フォルダのファイルまで破壊されたんだが・・

重複一致画面で順番が信頼性に足りないから、途中で反転してたりする。
Gドライブのファイル(新しいフォルダ)にずっとチェック入ってたのが、なぜか反転してEドライブ(整理済み)に入りだしたり・・
20万ファイル重複とか、1つずつチェックなんてできるわけがない。
やろうとしたが、あほくさくてやめた。200個で1ページのPageDownが1000回くらいかかりそうでw

拡張性も考慮してほしいな。無駄にファイルパスとか入れてるからメモリ溢れて停止するんだが。
とりあえず1000万ファイルは扱えるようにしてほしいな。

｢DBを作る｣のが目的。画像ファイル集めてたら100万とかすぐに超えるだろ。
本質的に｢焼いたファイル｣と｢いらないゴミファイル｣の区別はない。
そういう｢既にチェック済み｣のファイルを再チェック不要で、作業前に削除するのが重複検知ツールの目的。

だから｢持ってる旧来のファイル｣を消しちゃだめだ。

どんな使い方してんだよ
結果の見せ方は工夫できるだろうが
万単位で重複とか1000万ファイル扱えるようにとか（DB作るのか？
.NETのライトアプリには荷が重いし
はじめから271が求めてるスペックのアプリじゃない
もっと最初から想定した設計実装じゃないとだめ

パスは削除するファイル選ぶ材料になる。常に見えてる必要はないが

あとあほくさくならないインターフェイスってやつを考えて示してくれ
誰か作ってくれるかもしれんぞ

いや、難しくない、フォーマットの問題。

持ってる・いらないファイル.txt
######################
md5,ファイルサイズ,etc(ファイル名)
md5,ファイルサイズ,etc(ファイル名)

################

でリストを作る。
md5,ファイルサイズ だけでいいと思うが。

でこのリストのMD5 ファイルサイズから重複判定するだけ。
リスト作成で8割できたようなもの。
あとそのリストをどう処理するかはアプリを問わない。.NETだろうがVBだろうが同じ。

｢リスト優先主義(パソコン内ファイルだけじゃなくて、リストもファイル群とみなす)｣にしましょう
ってだけ。パソコンにおけるファイルなんてたかがしれてるし、
｢いらないファイルをPCに置きたくないだろ。｣あほらしい。HDDの無駄。
ウイルスとかグロ画像とかもう一度見ろと？ みたくもないよ。

｢これはいりません・orもう持ってます｣という情報だけを保存・整備したいだけ。

｢ゴミとして捨てたものを、また見つけて削除する｣って、前にやった作業をしたくないだけ。

ゴミ用ハッシュファイルを別で作って管理して
簡単な一覧、編集ツールつければできそうだな
重複じゃなくていらないファイルを探して削除する。と
需要ありそうなら検討よろ

持ってる.txt＝持ってるからいらない、その場で削除
前みたらゴミだった.txt＝ゴミだからいらない、その場で削除
ファイルサイズが未知→MD5チェック→両方未知＝ユニークファイル＝？？なのでとりあえず残す。

結局そのファイルはいらないわけで、持ってる＝ゴミ どっちも同じ事なのでリストは1つでもいいけどね。

所持ファイル(MD5,ファイルサイズ).txt
とくに画像ファイルは2つ3つ以上MD5が一致したら｢同じフォルダ認定｣でいいのかな。
動画ファイルは末尾が違う場合もあるから先頭データがいるとか？
動画はいいや。MD5,ファイルサイズだけで

md5って、どれぐらいファイル舐めるの？

ジャンボ宝くじに当たる程度の確率(300万分の1＝3*10^-6)にするには
100KBの画像だけで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が使えなくなるまで生きれるといいね!

ファイルサイズ併合でさらに3桁以上強度上げてるから
最短でも2060年かな。

良いフリーソフトは無いのか・・・

http://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0

ここでも読め

ちなみに俺が今使ってるフリーソフトは
UnDup1.5とBeRepetition1.5とFileMany1.1.1.4bな

正確にはUnDupはシェアウェアだが試用制限試用期限無しの事実上のフリーソフト
こんな事言ったら作者に叱られるが

UnDup速いけどUnicode対応してないのがなぁ
Beなんとかはハッシュ方式が選べるのがいいのかな
FileManyは更新が続いてる
用途に合わせて使い分けるとこの辺が選択肢か
類似画像検索もできるといいんだがスレチか

>>282
他にもいろいろあるよ
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/

探せばいくらでも出てくる
正しく使って大事なファイルを消してしまなわいように

AikoWinってのが使いやすくて愛用してるんだけど
２ＧＢ超のファイルがあると異常動作する。
きっと他にいいソフトがあるんだろうけど、
ひとつひとつダウンロード・インストール・試用・・・
とかメンドクセー

いろいろ使ってみたけどFileManyが一番動作が速いみたいだな
BeRepetitionは信頼性は高いけど遅い
FileHammerは.NETではなくネイティブアプリでサムネイルも見れるし速度もFileManyとだいたい同じ
いろいろルールを作って記憶させておける点がいい

もし自分で作るならFileHammerみたいなソフトにしたい

開発止まってるソフト多いな
みんな忙しいのか

>>285
FileManyはかなり速いが
設定項目が少なすぎな点が痛い
あと削除条件の動作があやふや
油断してると重複ファイルがあると両方消されで無くなるから困るｗｗ

不使用理由チェック削除済みソフト

Image 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 ４画面なリネーム機能４画面なリネーム機能ファイル管理ソフト ※ 内蔵ビューアが直ぐに落ちる

ｎ

最近FileManyばっかりだ

C#で書いてあるらしいけど一番動作が速いようだし
どういう訳か3日に1度ほど更新してる

>油断してると重複ファイルがあると両方消されで無くなるから困るｗｗ

なにそれ怖い

重複ファイルがあると両方を消す動作か
斬新だなwww

思いつかなかったわww

といいつつおまいらが作ると
ＡｖｓＢ　→　Ａを消す
ＢｖｓＣ　→　Ｂを消す
ＣｖｓＡ　→　Ｃを消す

みたいなのが出来上がるんだぜ

>>290
ファイル数31.6万、約170GB、重複数178というフォルダで比較してみた。
バイナリ比較での測定ね。

SDFMach　1593秒（デフォルト）
FileMany　　3213.2秒（1バイト単位で比較）

ソフトウェア板の方にもFileManyが速いって唐突に言い出した人が前にいたんだよな。
その時も、俺がUnDup、SDFMachと比較したんだが・・・
前より速くなったけど、遅いとしか言いようがない。

C#の限界だな
JITコンパイラで糞みたいなコード吐いてるだろ

DupFileEliminatorが最速らしいぞ

なるほどUnDupあればSDFなんとかは不要だな

>>296
やってみた。
ファイル数 316535、約168GB、重複数 180というフォルダでの比較。
バイナリ比較での測定ね。

すべて現時点での最新版を使用。
設定はだいたい同じ条件になるように（たぶん）してある。
検索結果は同じだった。

DupFileEliminator　588.1秒
SDFMach　　　　　　1595秒
FileMany　　　　　　 3093.3秒

やけに速いな。
DupFileEliminatorもC#らしい。

僕も作ってみるか

>重複ファイルがあると両方を消す

フルパスファイル名の比較で両方とも消さないようにできるはず。

300でレベルが知れた。やめとけ

でも片山先生は途中で投げ出さないぞ。

find + diff

find、sqliteでdb化、サイズ突っ込む、forぶん回し(md5を32k分)。
これなら数日で作れそうだ。

そうか

そうかそうか

FileManyは個人フォルダに今まで検索した結果をデータベース化して保存してるな
だから画像フォルダなどあまり変化がな所は検索すればするほど速くなるみたいだ

DupFileEliminatorは起動毎に一から検索をやり直す
だから初回起動時は一番速いが徐々にFileManyに抜かされるように思える
HDDの使い方にも大きく左右されるけどな

>>307
やってみた。
フォルダは>>298と同じ。中身は全く変わっていない。
前回のハッシュリストがそのまま残っているので2回目として再計測。

DupFileEliminator　588.1秒
FileMany　　　　　　 3093.3秒
　　　　　　　　　　　　648.6秒（2回目） ←New!

以前のバージョンだとハッシュリストを上手く使えてなかったけど、
今は有効に使えるようになったみたいだね。

3回目も計測したけど同じ結果だった。
フォルダの中身が同じなら2回目以降は同じになるのは当たり前。
何度計測してもこれ以上速くなることはないかと。

DupFileEliminatorほんとに中身バイナリ比較してるか？
サイズと日付けと何かであっさり比較諦めてバイト単位でみてないだろ
実際バイナリエディタで改変したら重複判断してワロタ

DupFileEliminatorはちょっと動作がおかしいぞ

表示されるサムネ見てみ
明らかに違う画像を同一ファイルと判定する場合がちょこちょこある

ベンチマーク以前の問題だな

数日経過したが

今の所FileManyのSHA256が一番安全か
すごい勢いでバージョンアップを繰り返してるし

>>309、>>310
類似じゃなくて重複の方での誤判定って事だよね？
いろいろ試してみたんだが、こちらでは誤判定するパターンを見つけられなかった。
誤判定するサンプルファイルを提示してもらえないだろうか。

自分で探せやカス
カンパウェアの癖に

カンパ！カンパ！　カンカン！　カンパ！

>>314
類似じゃなく重複で誤判定。再現方法は
動画みたいに100MB単位のデカイファイルを１つ用意
んでコピーする。このままだと重複
バイナリエディタでファイルのどっかを１バイト改変
更新日時とかが更新されるから
フリーソフト使って作成日、更新日、なんかを揃える
で、重複チェックすると重複と判断される

>>317
sha256までは一致しないだろ

>>317
ありがとう。 バージョン 20111016 で、メタデータ無視機能を使用してます？
該当するようであれば、20111106 を試してもらえないでしょうか。

驫麤

FileMany1.4.2.1b(最新版)で約300GBの700,000個ほどの画像の重複チェック

SHA256
時間はコンビニに出かけていて測ってないが、メモリは本当に食わないね
時間はさすがに掛かる

CPUはハッシュを計算している時30％ほど食っていたが比較中は5％程度
C#のライブラリが良く出来てるんだな

つーかSHA256を計算するのも

http://msdn.microsoft.com/ja-jp/library/system.security.cryptography.sha256.aspx

これがあるからなあ
ほとんど計算部分はプログラム必要ないじゃん
C/C++で書いたら大変だよこれ

検索中バックグラウンドにしまったらCPU使用率が2％、メモリ使用量も半分以下に
なってワロタ

表示にかなりのリソース食ってるな

作ったよ。まる２日掛かった。
http://www1.axfc.net/uploader/Sc/so/305512.zip

自己満足にも程がある

>>324 もっと具体的に。

おつかれ
もーいいよ

デバッグして0.1公開。
http://katahiromz.web.fc2.com/duperase/

FileManyスレ欲しいな
作ろうとしたが失敗した

ハッシュの衝突が怖くて全体が一致しているか調べるなら、重複している可能性の有るファイルを検出に
チェックサムやパリティーを使えば良くないか？

4byteか8byteづつ読み込んでXOR演算をしてやれば32bitか64bitの数値が手に入る。
後は、全体が一致しているか調べるだけ。

SHA256使えばまず衝突しねーだろ

>>330
衝突はしないと思うが、SHA-256の計算量ってチェックサムと比べるとどの位多いんだ？

ぐぐるって事を知らないのか
いくらでもサンプルプログラムが転がってるだろうが

でもテーブルを利用してるからそんなに多くはならない

UnDup 1.5gって一旦ソフトを終了して再実行しても、一度検索したフォルダに
対する再検索が、ディスクのアクセスランプもほとんど点かないで、ほぼ瞬時
(数秒〜10秒)で終わるんだけど、どこかにキャッシュしているんでしたっけ？

ちなみに検索設定は完全一致(1pass)で、PCを再起動した時の初回検索には、
同じ対象で重複を検索するのに5分強ほどかかります。

キャッシュした計算済みのハッシュを使う方法は、ファイルリンクの破損や
ウイルス感染、ファイルの上書き更新など、なんらかの原因でハッシュ計算
後にファイルが書き換えられている可能性を完全には排除できないと思います。

それと、ハッシュ値は1回のテーブル参照では求まらないので、シーケンシャル
アクセスで単純にバイト列を加算していくチェックサムに比べて、計算の手間は
膨大になります。

ファイルが大きくなるほど、同一サイズのファイルが存在する可能性は減る
ので、現実的な範囲であれば、サイズでふるいに掛けて、サイズが一致する
ファイル同士のみを、総当たり戦で完全一致で比較するほうが確実で早いと
思います。

UpDup遅いだろ

FileManyは使えば使うほど速くなる
でも時々hash.txtを消してやらないと残しておきたいファイルも過去に存在したと
いう理由で消されてしまうので注意

だんだん起動と終了がhast.txtの読み書きのために遅くなって行くしな

UnDupは対象ファイル数が増えると、極端に速度が落ちていく印象です。

実は、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を
呼んでいます。　ただし、検索結果をバッファへ記憶する際に配列要素の拡張
でオブジェクトのコピーが発生しないように注意を払い、すべてポインタ管理
にしています。(ソートも実体ではなくポインタを並べ替えるので要素が増え
ても速い)

>>335
期待している

俺が作るとしたらC++Builderでササッと作るけどな
MFCは結構面倒くてどうしてもVCLの手軽さに負けてしまう

画像の類似検索機能も有れば最強じゃね？

うぷよろ

とりあえず、検索結果のファイル読み書きとか、それなりに評価できる程度
にもう少し作り込んでから公開します。　アップロードしたら、あらためて
ここで告知させてもらいますんでよろしく。

画像の類似検索はOpenCVを使う予定で、幾つかアイデアはあるけど、試して
いる時間がない。

待ってます