 | | | | |
| Обход дерева каталогов с прерыванием и возобновлением или "Куда мы идем завтра?" |
Полный текст материала
Другие публикации автора: Паша Звягинцев
Цитата или краткий комментарий: | «... Недавно занимаясь интересной задачкой по написанию службы индексации, столкнулся с интересным вопросом: "А как бы нам поиск заморозить и продолжить после (через минуту, завтра, через месяц)?". ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 2 | 50% | | | | | Ничего особенно нового и интересного | | [2] | 2 | 50% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 4 | | | | Все понятно, материал читается легко | | [1] | 2 | 66.7% | | | | | Есть неясности в изложении | | [2] | 1 | 33.3% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 3 |
[Древовидные структуры] [Файловая система] [Поиск файла]
Отслеживать это обсуждение 
Всего сообщений: 910-07-2009 12:46С точки зрения избыточности сохраняемой информации - достаточно сохранить полный путь последнего обрабатанного каталога. Потом восстановить рекурсию будет гораздо проще - достаточно файнднекстом пройтись каждый уровень до соответствующего каталога - для этого НЕ НУЖНО обходить все дерево, только линейно для каждого уровня вложенности.
Насчет того что будут пропущена обработка какого-либо каталога или файла - для задачи индексации это не важно. Как только сканирование закончится всех папок оно в бесконечном цикле пойдет снова с самого начала и все файлы в конечном итоге когда нибудь будут обработаны. |
|
22-03-2006 13:38| мне кажется проще запоминать путь последнего найденного файла, потом при следующем запуске начинать именно с этого файла, тогда не надо будет делать столько примудростей, или я чего-то не понял |
|
30-06-2005 14:40сообщение от автора материала сорри, давно не появлялся, исправлюсь
касаемо последнего замечания
предлагаю провести лабораторную работу на тему функции FindFirst/next
результат могу предсказать - это мы привыкли к тому, что машина выводит нам файлы в каком-либо порядке, а вот в директориях оне лежат как бог на душу положит. И сортировка их - дело пользователя. Так что тогда запоминать ?
|
|
30-12-2004 12:31| Это, что новая мода присать все в одной функции? Ничего же непонятно, кождый логический кусок кода должен находится в отдельной функции или процедуре. Если неудобно то следует создать класс. |
|
20-12-2004 00:45сообщение от автора материала 1.насчет потоков - категорически согласен, так и сделано, но если как пример выкладывать большой кусок программы - запаришься читать и разбираться
2.запоминать место в качестве списка каталогов можно, НО это автоматом приводит к посторному просмотру текущих каталогов
3. ну а насчет сохранения всего списка файлов, а потом его обработки - ну случайно не работает в www.rambler.ru? Вот и поделитесь информацией как там ... |
|
19-12-2004 16:09>>>Application.ProcessMessages; // а вот без этого мы никогда не узнаем
>>> // что пора поиск закончить
Обычно для такого вида работ используют Thread.
абсолютно согласен.
А лично я бы для таких дел все-таки сначала полностью обходил все каталоги и запоминал размеры и дату файлов. После этого начинал бы обработку файлов. В случае прерывания работы запоминал бы время и размер только обработаных файлов. При следующем запуске сканирование файловой структуры и сравнение даты/размера обработанных в прошлый раз файлов и текущий размер файла. Если отличается, то обработку файла заного. Если появились новые файлы (даже в тех папках, которые мы уже обработали) то их тоже, конечно же, нужно обработать.
Так что запоминать место, в котором прервали сканирование особого смысла нету. |
|
17-12-2004 18:27| Предыдущее сообщение - мое, почему-то регистрация слетела. |
|
17-12-2004 18:23Интересно, сразу мне не было очевидно, что при восстановлении рекурсии в обратном порядке дерево каталогов не будет пройдено в каких-то местах еще раз. Но это, похоже, так и есть (дерево будет пройдено один раз).
Что касается типа string:
Типа TString в Дельфи нет. Есть статические строки старого типа, вроде string[250], и "длинные строки", для которых память выделяется динамически, по умолчанию тип string - это последнее. Если посмотреть, как реализованы функции FindFirst и FindNext (Дельфи 7), то можно увидеть, там такую строку
(привожу не буквально как в тексте модулей, а так, чтобы было понятно в отрывке)
type
TFileName = type string;
TSearchRec=record
....
Name: TFileName;
...
FindData: TWin32FindData;
....
end;
var F: TSearchRec;
F.Name := FindData.cFileName;
А в определении типа TWin32FindData видим.
cFileName: array[0..MAX_PATH - 1] of AnsiChar;
Поэтому F.Name по типу - все-таки обычная "длинная" строка, но реально ее длина не превышает MAX_PATH = 260.
Кроме того, в записи TWin32FindData есть поле cAlternateFileName, где, в случае длинного имени файла, хранится его древний :) усеченный вариант 8.3 .
Почему неправильно обрабатывался вариант со стандартной записью TSearchRec - не очень понятно.
Сообщение не подписано |
|
17-12-2004 13:54Может я не разобирался с написанным на 100%, т.к. в своей работе кажется только раз и пользовался обходом каталогов, но у меня сложилось впечатление, что ты не с того начал - начал с лечения не поставив диагноз.
В паскале допустим вызов функцией самой себя, но это не всегда оправдано и не всегда правильно.
А что тебе мешало найденные пути загонять в обычный StringList:
...процедуру не тестировал - из старого юнита вырезал...
DirList := TStrList.Create;
try
Pos := 0;
DirList.Add(От куда начинаем);
while Pos < DirList.Count do
begin
Err := FindFirst(DirList[Pos] + CAll, faDirectory, SearchRec);
while Err = 0 do
begin
if ((SearchRec.Attr and faDirectory) = faDirectory) and
(SearchRec.Name <> '.') and
(SearchRec.Name <> '..') then
DirList.Add(DirList.Items[Pos] + SearchRec.Name);
Err := FindNext(SearchRec);
end;
FindClose(SearchRec);
Inc(Pos);
end;
finally
DirList.Free;
end
......................................
и прирывать работу было бы легче. Я не настаиваю, может что-то упустил....
>>>Application.ProcessMessages; // а вот без этого мы никогда не узнаем
>>> // что пора поиск закончить
Обычно для такого вида работ используют Thread. |
|
|
|
