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

[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]

type идет после var, разве можно?

Как угодно можно. Количество блоков Var/Type/Const в программе не лимитируется, и порядок их расположения - тоже. Главное, чтобы все, что требуется нижестоящему блоку было уже описано в вышестоящем.

continue - фи, неструктурно!

Зато эффективно... Я не страдаю догматизмом. Если кому-то не нравится использование goto там, где оно может помочь разгрузить программу от излишней "структурности" (например, выход из 4-х вложенных циклов. Я не буду для этого добавлять логические переменные и условия) - это его проблемы. Я в таком случае использую безусловный переход.

Если я в самом начале цикла вижу, что мне его продолжать не имеет смысла - я не оборачиваю все остальное в Else, я сразу вызываю Continue, и цикл прекрасно продолжается.

Почему-то запуск fullcopydir('F:\T\', 'F:\G\', true) вне модуля program.

Ничего подобного. Посмотри внимательнее. Запуск FullCopyDir - это и есть вся основная программа, а все остальное - это описание самой процедуры FullCopyDir (вместе с ее подпрограммами).

Зачем SizeOf(Buf) вычисляется каждый раз, разве размер памяти под значение Buf меняется?

А ничего не вычисляется каждый раз. SizeOf вообще-то отрабатывает на этапе компиляции, ведь фактически размер переменной, которая назначена буфером, уже известен компилятору, если эту переменную можно использовать в качестве буфера. Так что здесь все в порядке, можешь SizeOf(i) на 1 не менять, не надо делать за компилятор его работу.

volvo, вашу он прокомпилировал - 134666 b.

Когда отладишь программу, зайдешь в Options->Debugger, включишь опцию "Skip all debug symbols from executable", и "Skip debug information generation", получишь EXE-шник в 2 раза меньшего размера. Я в таких случаях поступаю проще: когда мне нужен отладчик - я пользуюсь IDE FreePascal-я, когда программа отлажена, и мне нужен EXE-шник без отладочной информации - я просто открываю исходник в SciTE, и компилирую его оттуда: Scite + компилятор , тогда никакой лишней информации в EXE-файле не присутствует... Мне так проще, чем переключать режимы компиляции постоянно.

В то, что компилятор Дельфи (а не среда разработки) без багов как-то не вериться.

Семерка уже столько времени используется программистами... Там были, разумеется, баги, но они исправлялись, причем достаточно оперативно...