07/10/18 17:20:10
CD、DVD、HDDなどのファイルハッシュを計算しておきデータベースを作成して照合する
初めに64KB程度読み込んでハッシュを計算して、それが一致したら1MB程度ぶんずつ照合していく
ハッシュの計算方法は高速で、異なるファイルは異なる値を出すようにしたい
いちどブロックソーティングするといいとおもう
2:デフォルトの名無しさん
07/10/18 17:22:16
前に自分で立てたスレがあったよ すまん
3:デフォルトの名無しさん
07/10/18 17:25:02
では、ここではブロックソーティング中心に研究します
解説サイトをあげておきます
URLﾘﾝｸ(www.geocities.jp)
URLﾘﾝｸ(www.01-tec.com)
URLﾘﾝｸ(ja.wikipedia.org)
URLﾘﾝｸ(homepage3.nifty.com)
4:デフォルトの名無しさん
07/10/18 17:33:36
32KBから10MBまでのファイルをビット列と見なして、ブロックソーティングの符号化、復号化をなるべく高速に行うプログラムをつくろう
5:デフォルトの名無しさん
07/10/18 18:13:35
ソートの仕方は、例えば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進数の幅が大きい場合は、ランレングス圧縮 して登録するとよさそうな気がします
6:デフォルトの名無しさん
07/10/18 18:47:07
ブロックソーディングがしにくいのは、00000000000000000000000000000000とか
10101010101010101010101010とかのデータが出てきた場合
どうすればいい?
7:デフォルトの名無しさん
07/10/18 18:54:10
日本語テキスト、英語テキスト、exeなど別に辞書を作っておいて一度圧縮してからブロックソーディングいいかな?
8:デフォルトの名無しさん
07/10/18 19:19:53
>>1
宿題スレにレス来ているよ。
9:デフォルトの名無しさん
07/10/18 19:46:22
8ビットずつに区切って、ファイルごとに出現回数を求めて、類似するものを纏める
つぎに同分野ごとに出現回数からもっとも縮まる単語帳を作る
10:デフォルトの名無しさん
07/10/19 17:51:19
>>1
>いちどブロックソーティングするといいとおもう
なぜブロックソーティングするのか理解不能。
何も考えずにmd5でも計算したほうがよっぽど速いだろ。
今使ってる重複検出ツールはまずファイルサイズで確認するよ。
11:デフォルトの名無しさん
07/10/19 18:11:51
>>10
例えば、先頭1KだけでCRC計算するより、10Kを1Kに圧縮したものでCRCを計算した方がいいっていう発想
先頭が例えば空白ばかりのファイルが沢山あると区別がつかない
12:デフォルトの名無しさん
07/10/19 18:47:40
単発作ろうスレ立てるな上げるなリアルで死ね
13:デフォルトの名無しさん
07/10/20 04:49:48
>>10
やっぱそのまま64Kとか100Kくらいをハッシュ関数にわたしたほうが良さそうだな
14:デフォルトの名無しさん
07/10/20 04:58:14
重要なのは、合計のかかる時間なんだ
ファイルの読み込み、ハッシュの計算、比較の時間
どこにどの位時間をかけるかが重要だ
ファイルを沢山読めば、間違える確率は減るがそれだけ計算時間、読み込み時間がかかる
減らせば一致するファイルが多くなりこちらも比較に時間がかかる
15:デフォルトの名無しさん
07/10/20 04:59:37
よしまずは、ファイルの先頭何バイト読み込めば異なるファイルだと判別できるか確かめよう
16:デフォルトの名無しさん
07/10/20 05:15:17
先頭32Kでほぼ比較は出来るらしいことが判明した
17:デフォルトの名無しさん
07/10/20 05:21:37
32Kを直接比較するのと、SHA512やMD5に変換して比較するのではどちらが速いのか?
18:デフォルトの名無しさん
07/10/20 05:33:54
ハッシュですべき
19:デフォルトの名無しさん
07/10/20 05:40:34
ファイルの先頭から32K程度だと、動画の場合でオープニングシーンがある場合は比較が難しい
(オープニング/タイトルシーンは同じ場合であることが多いから)
ある程度ファイルのオフセットを取ってから比較すると32Kも比較しなくていい場合もある
ここらへんは、1.まず最初にファイルサイズが一致したら、2.先頭32Kを比較しても一致したら、
3.オフセットを取って比較ぐらいにするといいかも
20:デフォルトの名無しさん
07/10/20 06:25:37
同速度のHDD2つ、またはHDDとDVDを検索するとする
一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする
ファイルサイズと、CRC32を記録しようとすると一ファイルあたり8バイト必要
ファイル数は2^24個なので必要メモリは、最大128MB必要になる
これはスワップアウトを引き起こしてのろくなる原因になりうるが対処法はあるか?
ファイルの読み込みをドライブ別に読み込めば速度が出そう
21:デフォルトの名無しさん
07/10/20 06:27:07
板違いｳｾﾞｰよ
22:デフォルトの名無しさん
07/10/20 06:37:23
CRC16にしておけば、最大96MBで実用的か
あと肝心な事を忘れていた ファイル名とそのパスを記録する必要がある ここが一番メモリを消費する
ディレクトリ名は255文字位使えたような気がするのでメモリをくう
ハードディスクの格納方法を知ることが出来れば、文字列を全て記憶する必要はなさそうだが・・・
あとあらかじめサイズなどで比較の必要がないものはCRCの記録までやらなければメモリは減らせるが・・・
しかし、ディスクのシーク時間を考えると、一度ファイル名やサイズを取得したら一緒に32Kくらい読み込んだ方がとくということもある
>>19
ファイルのオフセットとは何でしょうか?
23:デフォルトの名無しさん
07/10/20 06:41:03
オフセットってのはファイル先頭からの距離の事
24:デフォルトの名無しさん
07/10/20 06:43:43
MD5の値を使って、ファイルの重複をチェックしている。データベースには700万個の
ファイルが登録されている。
最近、複数マシンに渡ってファイルを比較する機能を追加した。
25:デフォルトの名無しさん
07/10/20 06:44:46
>>1のプロファイル
・ヒキオタニート
・テラバイト級のストレージを持つ極度のny厨
・秘蔵のロリ画像・動画の収拾がつかなくなったから重複検出をせざるを得なくなった
挙句にム板でオナニースレとかどうしようもないゴミだな。
26:デフォルトの名無しさん
07/10/20 07:03:04
同一フォルダにおけるファイルとフォルダの合計数は、2^32-1個らしい 明確な記述は見つからなかったが・・
しかし、2^16個以上ある場合は無いだろうから、(a, b, c, ・・・) abcは2バイトの数字でファイルの位置は表せるな
ツリー構造を表現できれば、親ディレクトリの情報は共有できる
>>23
>>19のいうオフセットの比較がわかりません
27:デフォルトの名無しさん
07/10/20 07:14:28
ここいいよ
日本で現在最強の検索ツールundupの作者の開発ノートが置いてある
URLﾘﾝｸ(hp.vector.co.jp)
ファイルのパスだけど、一階層ずつ32ビット使ったとしてもある程度たまった時点でディスクに保存してしまえばメモリの消費から除外できるな
利用するのは最終的に重複ファイルが決まったときのみだからメモリにおいておく必要なし
28:デフォルトの名無しさん
07/10/20 07:15:12
>>26
多分「オフセットを取って比較」ってのは「ファイルの先頭から一定の距離に位置するデータを比較」の意味でしょう。
「ファイルからオフセットを取得して比較」（？）じゃなくて。
29:デフォルトの名無しさん
07/10/20 07:53:27
まずはドライブにあるファイルの、ファイルサイズと 先頭32KBのCRC16をメモリに格納する部分を作ろうぜ
ディレクトリ構造も保存しておいた方が良いけどコードがが煩雑になる これも入れたやつで速度を測った方が正確か
だれがもっとも速いアルゴリズムが作れるか競おう
CRCの計算方法はここにあるよ
URLﾘﾝｸ(laputa.cs.shinshu-u.ac.jp)
URLﾘﾝｸ(www.geocities.co.jp)
URLﾘﾝｸ(www.wdic.org)
>>28
意味理解しました しかしずらして比較するくらいなら、一度の多くを読み込んだ方がシーク時間が短くなりそう
30:デフォルトの名無しさん
07/10/20 08:01:29
>>27
そこのソフトの人の解説流し読みしたけど、かなり幼稚な印象だけど。
自画自賛？というか、もしかして1本人かな・・・
ファイルみたいな総数の判らん対象をオンメモリでソートなんて
やってる時点でソフト寿命はたかが知れてると思うよ。
31:デフォルトの名無しさん
07/10/20 09:04:07
>>27>>30
他のソフトと比較した上で言ってるの？
32:デフォルトの名無しさん
07/10/20 12:53:58
>>1とりあえず mail欄にsageっていれて投稿して
1,まず他のファイル重複検知ソフト(同業他社)が実装をどのようにしているのかのチェックを>>1はしたの？
2,ブロックソートとか行うと他のソフトとのハッシュ値の互換性がないけどどうするの？
>>1が作成したアプリケーションでしか、ハッシュ値の計算ができなくなるけど…
3,代表的な使用用途・検索するファイルの数/ファイルサイズ・ハッシュ結果のバイト数をできれば教えてください。
33:デフォルトの名無しさん
07/10/20 13:06:00
>>31>>32
日本一のファイル比較ツール作者のノートを読みましたよ 他のツールと比較しましたよ
>>32
ブロックソーティングはやめました
ハッシュ地に互換性は入りません そもそもファイル全体のハッシュ値では無い為、他と一致するわけがありません
>>32
条件はこれにしましたよ
同速度のHDD2つ、またはHDDとDVDを検索するとする 一つのファイルサイズは、2^32-1=約4Gバイト以下とする
ファイル総数は2^24=1600万以下とする
34:デフォルトの名無しさん
07/10/20 13:06:55
すみません Janeでsageほ固定しました 以後気をつけます
35:デフォルトの名無しさん
07/10/20 13:10:56
>>33
比較した他のツールってどれ？
36:デフォルトの名無しさん
07/10/20 13:20:15
>>35
このへん 対抗馬ってなかなか無いよ まともに動作しないのがほとんど ここ一年程度のは調べていないが・・・
URLﾘﾝｸ(www.nifty.com)
URLﾘﾝｸ(cowscorpion.com)
37:デフォルトの名無しさん
07/10/20 14:07:14
最近のやつしらべたら良さそうなのがあった 上はUNDUPとそれほど変わらないかも
URLﾘﾝｸ(www.vector.co.jp)
URLﾘﾝｸ(lucky.na.coocan.jp)
38:デフォルトの名無しさん
07/10/20 14:20:26
>>36
あとできればまともに動作しなかったのもおながい
39:デフォルトの名無しさん
07/10/20 15:43:36
ほとんどのやつはいい加減か動作が鈍い ファイルサイズしか調べなかったりする
40:デフォルトの名無しさん
07/10/20 16:03:56
>>33
レスありがとう。Image Hash Search みたいなものを、作るのかなと思ってたんだけど。
そうではなくローカル環境で動作する重複ファイルの検知ソフトを作るということだよね？
あと>>1で書いている重複という言葉は「バイナリレベルでの完全一致」ということでいいの？
たとえば画像とかの場合はヘッダーだけ違って中身は同じというファイルも多々あるのだけど。
私の質問がわるくてごめん。>>32の3はソフト使用者がどういう用途で、
パソコンを使用しているのかを考慮して、重複検知ソフトを作っているのかという話だったりします。
変な例で悪いけど、P2P使用者とそうでない人ではHDD内にある主なファイル種類・サイズは違います。
よってソフトもそれを考慮して最適化する必要があります。
41:デフォルトの名無しさん
07/10/20 16:08:26
『ほとんど』
って言葉できるだけつかわずに説明おねがい
42:デフォルトの名無しさん
07/10/20 16:28:55
>>40
バイナリの完全一致ですよ ファイルの種類での分類は考慮しない方向でいいと思います
というのも異なる種類なら先頭の方で不一致するからです
>>41
ほとんど ＝ UNDUPや上に上げたソフト以外
43:デフォルトの名無しさん
07/10/20 16:30:54
>>39
具体的に
44:デフォルトの名無しさん
07/10/20 16:32:04
ｇｄｇｄ
45:デフォルトの名無しさん
07/10/20 16:34:46
いい加減なツールは >>36にある
46:デフォルトの名無しさん
07/10/20 16:36:55
調べた時の条件は？
47:デフォルトの名無しさん
07/10/20 19:26:29
>>1しか読んでないが、ファイルサイズとMD5を保存しておいて比較するだけでいいんじゃね？
48:デフォルトの名無しさん
07/10/20 19:29:41
>>47
3GのMD5を計算するのにどれくらい時間がかかるんだろか? なるべく高速、低メモリが重要
49:デフォルトの名無しさん
07/10/20 19:31:33
目的とか目標って何なの？
既に高速なツールはあるけどもっと高速なのを作りたいの？
50:デフォルトの名無しさん
07/10/20 19:31:57
以前PerlとMySQLで、エロ画像の重複チェックしてたなぁ。
飽きて放置したまんまだけど。
51:デフォルトの名無しさん
07/10/20 19:36:41
既に高速なツールあるとはどれですか?
52:デフォルトの名無しさん
07/10/20 19:39:14
>>48
こういうのって重複したファイルを削除したいってのが目的だから、
サイズの小さいファイル(数百KBの画像とか)をターゲットにしているんじゃないの？
そこらへんが>>1に書いてないからよーわからん。
53:デフォルトの名無しさん
07/10/20 19:43:15
>>52
サイズ小さくても、ディスク一杯に詰まっていたら、500G程度読み込んでMD5を計算することになるよ
なるべくディスクの読み込みを減らして比較できた方が良い
54:デフォルトの名無しさん
07/10/20 19:44:33
1kb～数gbのどんなサイズでも最高速に動くアルゴリズムなんて
30秒で思いつかなきゃ素質ないね。
55:NOT 1
07/10/20 19:58:11
>>43
いい加減なソフトが多いのは事実だと思うよ。
・なにをもってファイル重複としているのか、マニュアルなどに書いていない。
・NTFSのリパースポイントをソフト側で考慮していない。
すぐにあげれる問題としてはこんなとこ。
56:デフォルトの名無しさん
07/10/20 22:09:44
ルートディレクトリ(c:\)を入力したら、ファイル名とサイズと先頭32Kを読み込む
ファイルは読み込んだ順に連番をつける
ファイル名とその配置、ディレクトリ名はディスクに書き出し、ディレクトリ名とファイル番号とサイズとCRCはメモリに保持する
ディレクトリがあれば最後に進める いくつまで進めたかを記録しておく
調べるディレクトリがなければ上へ戻る
57:デフォルトの名無しさん
07/10/20 22:11:49
もうｇｄｇｄって感じだな
58:デフォルトの名無しさん
07/10/20 22:17:14
所詮割れ厨だしな
59:デフォルトの名無しさん
07/10/20 22:33:11
>>56
最初からファイルの先頭読んでく必要ないでしょ。
同一サイズのファイルが出てきた時に初めてやればいい事だし。
つーかアルゴリズムもっと勉強しなさいよ。
辛いんだよこのスレ＞＜
60:デフォルトの名無しさん
07/10/20 22:38:45
>>59
>>27をよんで下さい
ディスクのシークにかかる時間を考慮すると、その位置にある時にまとめて同ディレクトリのファイル内容を
取得してしまった方が速いようです
ここです
ソートを行って検索すべきファイルを減らした後で、今まではファイルサイズの順番に従って検索していたのを、
ディレクトリの並び順にCRCを計算していってメモリに記録し、後でファイルサイズ順にCRCを比較していく事にした。
テスト環境では従来の完全比較に比べ半分以下の時間ですみ、簡易検索の後に残った重複している可能性のある
ファイルを完全検索しても充分にお釣りがくる結果となった。
実際にはＭＯの様な極端にシークが遅いのでランダムアクセスが大きな負担にならない様なメディアや、
ほとんどが重複していて簡易検索では候補を絞れないためその後の完全検索で時間がかかり過ぎる場合など、
この新方式では高速化されないケースもある
61:デフォルトの名無しさん
07/10/20 22:49:23
なるほど。
エントリ読みに行ったついでにクラスタサイズ程度読むのは有効かもな。
62:デフォルトの名無しさん
07/10/20 23:46:13
基本はwindows APIを直接使う方がいいだろうな 速度的に いま>>56を作っている
63:デフォルトの名無しさん
07/10/21 00:01:22
普通に作ると一度実行するとファイルの中身がキャッシュされるので、メモリに収まるような少量のデータでテストすると１回目と２回目以降ではDISKアクセスに関してはまったく異なる挙動になります。
そこも考えてプログラムもテスト用データも作る必要がありますよ。
64:デフォルトの名無しさん
07/10/21 00:45:51
とりあえず簡単の為にCreateFileで一度アクセス出来なかった物は存在しないものとしよう
しばらくしたらアクセス出来る物もあるとは思うが・・・
CRCの計算、ファイルの読み込み、ファイル情報の書き出しを並列化できるとおもう
情報の書き出しはある程度サイズが貯まったらにして、CRCの計算はほとんどかからないだろうから
実質的には読み込み時間だけですむと思う
65:デフォルトの名無しさん
07/10/21 00:52:56
あともっとも時間がかかるのは、サイズのでかいファイルが一致してしまう場合なんだよな
1Gのファイルが一致すれば、まともにやると2Gぶん最後まで比較しなければならなくなる
最大、比較サイズを決定してしまうという方法はある たとえば全体の30％ OR 100M 一致すればあとは検査しないとか
あとは、1MずつにCRC計算しておいてデータベースに入れておけば半分ですむ
>>63
テストデータは作るの難しいと思うので直接CやDドライブを実験台にしようと思います
66:デフォルトの名無しさん
07/10/21 00:54:36
わざわざBBSに独り言を書き込まずにはコーディングできないのかね
67:デフォルトの名無しさん
07/10/21 02:31:25
1Kバイトのファイルが10万個とかある比較がと大変だな 同サイズのファイルはせいぜい1万個くらいな気はする
小さいファイルを沢山生成してテストするか こうなると中身を読んだ方が断然いい
68:デフォルトの名無しさん
07/10/21 03:35:17
頭大丈夫か
69:デフォルトの名無しさん
07/10/21 12:52:05
unixのコマンドの組み合わせでできたような
URLﾘﾝｸ(en.wikipedia.org)
winで動くのもあるね
70:デフォルトの名無しさん
07/10/21 16:28:37
URLﾘﾝｸ(fx10.web.fc2.com)
テストデータを生成します 5分ほどかかるかと思います
現在最速ソフト
URLﾘﾝｸ(www.vector.co.jp)
第二位
URLﾘﾝｸ(www.vector.co.jp)
71:デフォルトの名無しさん
07/10/22 14:17:25
ハードディスクの内蔵キャッシュは書き込み、読み込みなどを高速化するように並び替えするの?
それとも書き込む順番どおりなの?
72:デフォルトの名無しさん
07/10/22 14:29:26
CRC32の計算方法とテーブルってわかる人いますか?
73:デフォルトの名無しさん
07/10/22 14:40:48
URLﾘﾝｸ(kone.vis.ne.jp)
ここらへんにかいてあるが不明
74:デフォルトの名無しさん
07/10/22 14:52:13
はやいコードをコピペすればいいか
75:デフォルトの名無しさん
07/10/23 02:26:19
途中まで書いたが眠いので途中までしか無い
m ディレクトリの階層の深さ
n 見つかったファイル総数
M 最大階層数
N 最大ファイル総数
dirname(i) 各階層のディレトリ名
dirban(i) 何番目に上のディレクトリが見つかるか
file(k) 現在調べているディレクトリでのファイル情報( 名前、サイズなと゛)
filesyori () {
path = dirname(0) +・・・+dirname(m)を開く
k=0;
if ( file(k)がファイル)
76:デフォルトの名無しさん
08/01/14 22:01:09
さて、進んでいるかい？
77:デフォルトの名無しさん
08/01/18 22:01:30
ファイル検索のDLLは作るから、GUI部分を作ってくれ。
78:デフォルトの名無しさん
08/01/18 22:09:30
まかせろ
79:デフォルトの名無しさん
08/04/19 04:05:56
誰もいなくなった？
UnDup にデータベース機能がついた様なソフトが
理想形となってるみたいですね。デスカ？
80:デフォルトの名無しさん
08/04/19 17:26:50
俺が使ってるのは多分ファイルサイズくらいしか見てないと思うが、そんな死ぬほど遅いわけじゃないけどな
同サイズのファイルが大量にあると若干遅くなるけど
81:デフォルトの名無しさん
08/04/19 17:36:38
>>79
それ考えたけど、データベース作成後に
ファイルが更新されているかどうかを調べるのが困難。
HDDだと書き換えられるから、全体を再チェックしなくてはいけなくなる。
それにデータベース作成時間程度かかる気がする。
82:81
08/04/19 17:40:24
データベースをチェックしないままだと重複ではないものを、重複と間違えることが出てくるけどこれは大したことでは無い。
しかし、重複であるものを、重複とみなさないケースが出てきてこれを見つけるのが困難になる。
結局、全部検索することになりそう。
83:デフォルトの名無しさん
08/04/19 17:46:22
てか、そもそも何故DBを使うの？
重複検出を一回やるだけなら全部オンメモリで処理しても足りると思うんだけど。
後で別の重複検出をやるときにDBに入れたデータを再利用するってことなのかな？
そうそう再利用できるケースがあるとも思えないけど…そんな同じファイルを何回もHDD上に生成したりするものだろうか？
ファイルのハッシュ値と詳細を記録するとかだったらまだわかるんだが。
84:デフォルトの名無しさん
08/04/19 17:47:41
DVDとCDは書き換え不能とし、それだけデータベース化するなら簡単だけどね。
85:デフォルトの名無しさん
08/04/19 17:50:14
>>83
おもな利用方法はCD、DVDとの比較と思います。データベース導入ならHDDもしないと不自然だなと思うわけです。
86:デフォルトの名無しさん
08/05/03 08:42:33
UNDUPを超えるソフト作ってシェアウェアにすると幾らくらい売れますか?
500円として100個は売れますか?
87:デフォルトの名無しさん
08/05/03 08:48:34
UNDUPで十分なので売れません
88:デフォルトの名無しさん
08/05/03 09:01:50
UNICODEや長いファイル名に対応していなくて、落ちやすいバグがありますよ
あとデータベース機能機能もつけて、UNDUPの速度を半分以下にしたら幾らくらいですか?
89:デフォルトの名無しさん
08/05/03 09:07:28
シェアウェアにするなら最低でも1000円にしておけ。
500円でも1000円でも売り上げ本数は変わらんだろう。売れるかどうかは別問題だが。
90:デフォルトの名無しさん
08/05/03 09:24:44
速度を半分以下にするのか。遅いな。
91:デフォルトの名無しさん
08/05/03 09:30:02
シェアウェアで小ヒットするといくら位なんですか?
92:デフォルトの名無しさん
08/05/03 11:35:23
あー、昔作ったことあったわ
93:デフォルトの名無しさん
08/05/03 14:35:46
シェアウェアにするほどの価値はあるのか？
どうでもいいのに金払うのが面倒だろ
94:デフォルトの名無しさん
08/05/03 17:50:17
優秀な最大公約数的なソフトがフリーであるのに、
わざわざ得体の知れないシェアを使おうとは思わないな。
それに使うとしても月に一回ぐらいだろ?
95:デフォルトの名無しさん
08/05/03 18:49:16
UNDUP (600円) に対抗して、使用制限無しで500円の販売したらいくつ位売れるのかと
思ったんです。大して売れなくても良いんですけど、
UNDUPを完全に上回ったとしたらどの位かなとおもったんです。
96:デフォルトの名無しさん
08/05/03 23:30:51
自分でそういうソフトを選ぶ基準から考えてみろ。
UNDUPがあるんだし、他の、しかもシェアウェアを
わざわざ選ぶ理由なんてあるか？ゼロだろ。
買われるとしたら、検索もできないネット覚えたての
情報弱者がたまたま最初にみつけて、間違えて買うぐらいだな。
今時小学生でもありえないが。
UNDUP程度なら誰でも作れるんだし、ここでぐだぐだ
売れるかどうか、なんて書いてる奴のソフト、しかも
猿真似のシェアウェアが売れると思うか？
この程度のソフトなんて作っても金にならんぞ。
オクで転売でも始めた方が儲かるんじゃないか？
97:デフォルトの名無しさん
08/05/04 11:28:30
完全フリーにして名前売った方が後々儲かるかも。
98:デフォルトの名無しさん
08/05/04 17:29:09
空気読まずに書くよ
全ファイルのMD5とかSHAハッシュ取ってsortコマンド使えばええやん
殆ど重複はしないでしょ
でかいファイルは4MBくらいで読むの止めて、サイズ一緒に出力しておけばいいし
99:デフォルトの名無しさん
08/05/04 19:56:15
>>98
小学生は大人になってから来てね
100:デフォルトの名無しさん
08/05/20 00:25:58
データの比較方法はわからんが>>1が言うのはこういうのか？
URLﾘﾝｸ(www.vector.co.jp)
101:デフォルトの名無しさん
08/05/25 22:20:27
容貌
画像MD5比較で条件付削除ができるようにして
102:デフォルトの名無しさん
08/05/25 23:09:45
>>101
どんな面しているんだか。
103:デフォルトの名無しさん
08/05/26 00:01:49
どういう意味かと思ったら、容貌から来てるのね。
104:デフォルトの名無しさん
08/05/28 09:02:17
今から作るなら画像／音声／動画の類似性をチェックするぐらいの意気込みでお願いしたい。
105:デフォルトの名無しさん
08/07/19 12:49:02
こんなんで用が足りてますが何か
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;
}
}
}
106:デフォルトの名無しさん
08/08/18 19:07:30
sage
107:デフォルトの名無しさん
08/08/22 06:34:19
UNDUPおせえｗ
Win32API使ってる時点でこれが限界か
しかし>>1の着眼点面白すぎだな
2^24個のファイルってMFTが16Gになるぞ
その上ファイルサイズは4G制限かｗ
てかたった1年前の話なのにCRC16とか出ててフイタｗ
5年位前のカキコかと思ったわ
108:デフォルトの名無しさん
09/01/06 09:05:41
ほしゅ
109:デフォルトの名無しさん
09/01/06 15:18:16
ハッシュとファイル名をペアにしたキャッシュは取ってんの？
大方>>1の見え透いた用途では、古いファイルが変更される事は
少ないんじゃないか？だったら
キャッシュ.txt:
最終更新年月日
MD5等ハッシュ ファイルパス
MD5等ハッシュ ファイルパス
MD5等ハッシュ ファイルパス
・
・
・
とファイルをフォルダごとに作っておいて、比較対象は最終更新年月日より
タイムスタンプが新しいものに限ると。これだけで>>1の様な用途なら十分
高速に使えると思うぞ。
110:デフォルトの名無しさん
09/01/06 16:56:49
見え透かせるって事は同類か
111:デフォルトの名無しさん
09/01/07 01:56:44
URLﾘﾝｸ(www.vector.co.jp)
これはどう？
112:デフォルトの名無しさん
09/01/10 03:04:16
複数のDVDにバックアップしたデータをまとめてブルーレイに焼きたいのです
でもかぶってるファイルが多数あるのでそれらをまとめてから焼きたいのですが
どうすればいいですか？
113:デフォルトの名無しさん
09/01/10 03:16:16
板違い
114:デフォルトの名無しさん
09/01/10 23:24:31
>>113
ファイルの重複検出ツールのスレですよね？
115:デフォルトの名無しさん
09/01/10 23:33:18
>>114
で、お前はどういう方針でツールを作ろうとしてるの？
116:デフォルトの名無しさん
09/01/11 01:31:35
ってか、システムにファイルを通す際に必ず同じプロセスを通過するようにすればいいんじゃないかなあ。
ファイルコピー→＜ファイルチェックプロセス＞→ディスク
って感じで。
ファイルサイズとかハッシュが同じファイルを通そうとしたら弾くとか。
117:デフォルトの名無しさん
09/01/11 04:22:32
>>116
馬鹿発見
118:デフォルトの名無しさん
09/01/11 11:05:58
>>114
重複検出ツールを「作ろう」ってスレだろ、ＪＫ
119:デフォルトの名無しさん
09/01/12 10:11:42
>>118
その成果だけ頂きたいのです、女子高
120:デフォルトの名無しさん
09/01/12 10:53:45
そういうやつはこっちだ
ｽﾚﾘﾝｸ(software板)
121:デフォルトの名無しさん
09/01/13 15:44:22
>>119
未成熟ぎみなのがいいんです、JC
122:デフォルトの名無しさん
09/01/14 13:42:17
数十万個のファイルの中から指定のファイルとほぼ同じ内容のファイルを高速に検索する
方法はないでしょか？
完全一致のファイルならファイル名と MD5 のデータベースを作っておけばファイル数に
関係ない時間で検索できるのですが。
123:デフォルトの名無しさん
09/01/14 14:25:20
>>122
ある通信プロトコルでの相手を決定するための方法だけど、
その数十万個分のファイルに対応するオブジェクトを作る。
指定のファイルのオブジェクトのビット(特徴)を、1こずつそれらに送る。
同じビット(特徴が一致した)なら応答を返す。
応答が最も多かったファイルを「ほぼ同じ内容」と判断する。
ようするに、比較をインクリメンタルにやるという話。
ハードウェアでの通信だと一瞬で判定できる。
それをソフトウェアでやると個数分の時間が掛かる。
まあ総当りするよりは速い。
124:デフォルトの名無しさん
09/01/14 14:31:22
ファイルの一部のMD5つくれば? とる位置を3カ所くらいにして、それが一つでも一致すれば疑わしいとする。
あとは人間が確認する。
125:デフォルトの名無しさん
09/01/14 14:35:59
どうせ、画像ファイルだろ。MD5を作るんじゃなくて、サムネイル画像作ってそいつで比較したら?w
126:デフォルトの名無しさん
09/01/14 14:39:27
画像なら、画像の特徴を比較する必要有り。部分md5では無理
127:デフォルトの名無しさん
09/01/14 17:40:08
サムネイルもインデックスみたいなもんだな
128:デフォルトの名無しさん
09/01/14 22:02:32
最近のコンピュータは高速だからファイルの先頭から1ビットずつ比較しようぜ
129:デフォルトの名無しさん
09/01/14 22:04:27
指紋認証のやり方で特徴点抽出
130:122
09/01/15 14:04:06
122 ですが、ファイルは主にプログラムのソースコードです。
現在使っている MD5 以外の検索方法は
ベースファイル名が一致しファイルサイズが近いものを DB から抽出し、
ファイルの最初の 128KB のバイナリ差分が小さいものに絞り込み、最後に
ファイル全体のバイナリ差分が小さいもの選んでいます。
この方法でそこそこの時間で検索できますが、大幅な絞り込みのために
ファイル名を使っているのでファイル名が全然違うファイルは検索対象に
ならないので困っています。
131:デフォルトの名無しさん
09/01/15 14:27:57
先頭32K(違いが出なかった場合は32K-64K、64-96Kなど)
のMD5を保持しておけよ。
132:デフォルトの名無しさん
09/01/15 14:48:45
ハッシュじゃ類似判定できないだろ
133:デフォルトの名無しさん
09/01/15 15:00:17
ベクトル空間法 類似
でぐぐれ
134:デフォルトの名無しさん
09/01/15 15:09:56
>>130
ソースコードならクラス、メソッド名だけ抽出して比較すりゃ終わりじゃね？
もっと確度上げたいなら変数名も追加
135:デフォルトの名無しさん
09/01/15 15:24:00
バージョン違いのさはどうするんだ
136:デフォルトの名無しさん
09/01/15 19:07:03
調子のんなよカス
137:デフォルトの名無しさん
09/01/15 19:12:13
>>135
お前の恥ずかしさに免じて何も指摘しないでやる
138:デフォルトの名無しさん
09/01/15 19:27:30
クラス名などが一致しても、コードの中身がバージョンのズレにより
大きく代わることがあるだろ。
139:デフォルトの名無しさん
09/01/15 19:28:19
初めから書き直したりした場合だ。
140:デフォルトの名無しさん
09/01/15 19:35:05
>>138
お前なぁ、自分で墓穴掘ってちゃ世話無いだろうが
もう分かったから、そのまま墓穴に埋まっててくれ
141:デフォルトの名無しさん
09/01/16 12:21:29
Mr.Driller 好きだぜ
142:デフォルトの名無しさん
09/01/16 12:27:17
ゆ○ぽのことか？
143:デフォルトの名無しさん
09/01/18 07:35:52
中に特定の文字列がある穴を探して埋まっておけばいいんじゃね
ソースコードだったら大体同じようなクラス名や関数名で書いてるだろ
分かりにくいコード書いてるやつがいたら穴掘って埋めればおｋ
144:デフォルトの名無しさん
09/01/19 10:40:44
undupとかの重複ファイル検索ソフトの比較スレがあったと思ったんですが、見つかりません。
どなたかご存じないですか？
145:デフォルトの名無しさん
09/01/19 11:21:29
お勧めの重複・類似・近似画像処理ソフト2
ｽﾚﾘﾝｸ(software板)