проблемы работы с директориями Опции

[ddn]

Есть много вопросов по работе в BP7, TMT (3.90), FPC (2.4.0.i386-win32) под WinXP:
1) верно ли, процедуры FindFirst и FindNext могут одновременно работать с несколькими директориями и даже с одной директорией через несколько указателей;
2) верно ли, что указатель поиска в директории определяется только записью файла SR (тип TSearchRec), но не директорией в которой она расположена, т.е. только по записи файла SR возможно непосредственно определить ее директорию и ее расположение в директории;
3) верно ли, что вызов FindNext(SR) возвращает в SR следующую запись (если она есть, если нет - SR неопределено или исходное значение?) в директории ее (исходной записи SR) расположения, а не в директории из последнего вызова процедуры FindFirst;
4) верно ли, что вызов FindClose(SR) прекращает поиск (работу с указателем) в директории расположения записи, а не в директории из последнего вызова процедуры FindFirst, поиск в других директориях не прекращается (непонятно, зачем вообще нужна эта процедура, если вся работа идет с данными из записи SR);
- без выполнения данных взаимосвязанных утверждений рекурсивный поиск в директориях НЕВОЗМОЖЕН (по крайней мере, без создания списков их содержимого),

далее:
5) верно ли, что путь к директории в вызове процедуры FindFirst должен заканчиваться разделителем '\';
6) возможна ли проверка существования файла, директории или лог. диска по его имени/полному_имени без использования процедур FindFirst и FindNext;
7) возможна ли работа с текущей директорией (получение абс. пути, изменение);
8) верно ли, что имена директорий SR.name в их записях SR из их наддиректорий не содержат разделителя '\';
9) верно ли, что записи в любой не изменившейся директории при каждой ее обработке процедурами FindFirst и FindNext выдаются в одном и том же порядке (лексикографическом по именам?);
10) как обеспечить работу с длинными именами файлов (как вызвать Win под FPC);
11) верно ли, что поле Time в TSearchRec - это время создания файла (если нет, как узнать/изменить время создания), или это время его последнего изменения/открытия;
12) что представляют собой неизвестные компилятору типы полей записи SR файла в директории под Win: TFileName (=string ?), THandle, TWin32FindData, каким характеристикам файла они и Fill (тип array[1..21] of Byte) отвечают;

Win32 target
type
  TSearchRec = record
    Fill : array[1..21] of Byte;
    Attr : Byte;
    Time : Longint;
    Size : Longint;
    Name : TFileName;
    ExcludeAttr : Longint;
    FindHandle : THandle;
    FindData : TWin32FindData
  end;

[volvo]

моя программа в принципе должна работать правильно.

Если не работает - значит не должна. То, что должно - работает. Задачу свою озвучь, а то что-то написал, да прямо сейчас я все брошу и буду из комментариев вычленять информацию о том, что и как ты там делаешь, после Maple-то...

Я видел этот пример. Хотя я стараюсь не использовать рекурсию, стараюсь сделать стек через file или array. Эта же рекурсия меня насторожила, она усилила мои подозрения, что допустим только один поиск единовременно.

Ты хочешь на Паскале писать в стиле Maple? Если он "не умеет" рекурсию - то это не значит, что надо ВЕЗДЕ обходиться без рекурсии, правда? Паскаль рекурсию готовить умеет, причем прекрасно. Программа получилась (заметь, в отличие от твоей) четкая, ясная и понятная. В твоей же без особого ковыряния и не разберешься.

Знаешь, в чем твоя ошибка? Это называется антипаттерн ""Золотой Молот"" Тебе кажется, что другого способа работы с вложенными папками, кроме как создание лишних сущностей в виде стека (зачем создавать стек вручную, если при использовании рекурсии это без тебя прекрасно сделает компилятор?) или файла - не существует. Однако, это не так. Существует. Рекурсия. Каждая папка - это "копия" папки - родителя, в том смысле, что работать с ней надо абсолютно так же, открыть новый поиск (кто говорил, что нельзя? Ты не закрыл первый, а уже открываешь второй, заметил?) вызвав FindFirst, потом пока не произойдет ошибка - вызывать FindNext, и в конце закрыть поиск FindClose. Всё! Больше тебя ничего не должно интересовать, заметь. Если тебе по пути встретится еще одна папка - ту просто войдешь еще глубже в рекурсию, и опять будет (автоматически!!!) сделано то же самое - FindFirst/цикл FindNext/FindClose. И (О, Чудо!!!) Когда ты выходишь из очередного уровня рекурсии на предыдущий - память высвобождена корректно, все переменные из стека удалились (это гарантирует компилятор), ничего лишнего не остается...

Чем не устраивает этот подход, можно рассказать? (только не так многословно - коротко по пунктам: раз - это плохо потому что:... ; два - это ужасно - потому что:... ; три - это неприемлемо - потому что... ; четыре - это вообще не будет работать никогда - потому что: ... ). А потом я покажу свой вариант программы. Рекурсивный. Который с большой степенью вероятности будет а) меньше, причем значительно, по размеру; б) быстрее за счет того, что не будет работать с самописным велосипедом, а будет работать с тем, с чем прекрасно умеет работать компилятор - со стеком вызовов; в) гораздо более понятной, чем твой код, ибо рекурсия. Возможно, ее сложнее написать, но читается она гораздо проще итерации, в особенности - когда итерация эту самую рекурсию эмулирует...

Хм, интересно, что будет, если каталог изменяется во время поиска?

Получишь ошибку "и всего делов". А поскольку ты ошибки не обрабатываешь (возможно, в Maple так принято, но Паскаль - это не Maple), то просто вылетишь из программы с предложением отправить Дяде Биллу письмо...

Все, что от тебя сейчас требуется - это забыть все то, что ты умеешь делать в Maple, и научиться правильно работать с файлами/папками на Паскале. Как делать правильно - я тебе уже написал. Если хочешь - расскажи, что делает твой код, я напишу тебе для примера рекурсивную функцию, которая будет делать то же самое.

Мне требуется ясная работа с файлами и без ограничений.

А ограничений и нет, если правильно пользоваться тем, что предоставляет язык. Ограничения появляются, когда ты пытаешься НАВЯЗАТЬ языку свои представления о том, как нужно делать. Не навязывай - ограничения исчезнут сами собой...