Тут умные книжки говорят, что хеш таблицы очень круто.
а вин апи - бытро.
задача по работе с файлами.
+ |
procedure TForm1.Button1Click(Sender: TObject);
var
hd:Cardinal;
fnm:string;
//rec:TSearchRec;
rec1:_win32_find_dataa;
FindHandle : THandle;
FindData : TWin32FindData;
b:boolean;
s:string;
begin
//search;
// fnm:='c:\*.*';
FindHandle := FindFirstFile('C:\*.*', FindData);
if FindHandle <> INVALID_HANDLE_VALUE then
begin
b := true;
while b do
begin
s := FindData.cFileName;
if (FindData.dwFileAttributes and FILE_ATTRIBUTE_DIRECTORY)>0 then s:=s+' dir';
// не показывать
if (s<>'..') and (s<>'.') then
Listbox1.Items.Add(s);
b := FindNextFile(FindHandle, FindData);
end;
end;
FindClose(FindHandle);
end; |
вот маленькую заготовку сделал - вычитываю в структуру TWin32FindData информацию о найденном файле (дальше будет рекурсия по директориям, не за нее сейчас речь)
потом надо обработать найденное. т.е. сверить имена, размеры, даты и совпадения юзеру предъявить.
вот с этого места про хеш таблицы.
так понял всю структуру хранить - не надо.
т.е.
Tfrec = record
parentdir: pointer;
ftLastWriteTime: TFileTime;
nFileSizeHigh: DWORD;
nFileSizeLow: DWORD;
cFileName: array[0..MAX_PATH - 1] of AnsiChar;
end;
будет хватать.
дальше рекомендуют сделать CRC стоке. cFileName = строка. была мысль сделать ftLastWriteTime+ nFileSizeHigh +nFileSizeLow+cFileName = строкой и ее хешировать.
и потом по поступлении новых Tfrec смотреть вновь полученный хеш - и если там уже что-то есть = решать про коллизии и подвязывать новый эллемент или определять что это совпадение и сигналить за это юзеру.
если CRC16 то 65536 + коллизии = массив на мин 128kb (вроде не смертельно)
потом Tfrec все равно придется где-то в памяти хранить (иначе как понять колизия ли) + если таки будет 2 элеменка на 1 ключ,
это доп цикл с пробежать по всем элементам структуры + сравнение cFileName = медленно. а если еще при этом пробегать все позиции ветки с одним ключем...
допустим даже если cFileName = cFileName делать через исключающее или (чтоб бодрее) - есть неясность с длинной записи.
тут вот пытался поискать, из того, что есть готовое по заявленной проблемме.
есть TBucketList (но что-то его ругают. с хелпом там немного не понятно. )
есть чувство, что в винде что-то подобное уже реализовано, отполировано, и просто я не знаю как это достать из апи.
Внимание вопрос:
1) есть ли в винапи что-то наподобии хеш -таблицы, которой можно безбоязненно воспользоваться для описанного выше?
2) просьба подсказать по вин апи, что глянуть по теме.
3) есть ли БЫСТРЫЙ способ не создавать мегабайты в памяти с информацией про файловую структуру - а работать с указателями (подозреваю, что должно быть)
Спасибо за ответы и подсказки.
п.с. если делать элемент хеш таблицы так : ключ - указатель на структуру; указатель на след элемент; и ориентироваться на nil - как на конец ветви = нормальный подход?