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

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

Ты для начала переведи то, что написано выше на нормальный русский язык...

верно ли, что вызов FindNext(SR) возвращает в SR следующую запись (если она есть, если нет - SR неопределено или исходное значение?) в директории ее (исходной записи SR) расположения, а не в директории из последнего вызова процедуры FindFirst;

Это что тут написано, можно объяснить? Какая директория последнего вызова FindFirst? Какая директория "ее (исходной записи SR) расположения"? Ты о чем вообще?

Чтобы инициировать поиск файлов вызывается FindFirst с указанием папки и маски для имени файла. Если файл, имя которого соответствует маске, найден - DosError = 0 (и SR содержит корректные данные), если нет - DosError = 18. Потом продолжаем искать файлы в той же папке, где начали FindFirst-ом, но уже с использованием FindNext. То же самое: файл найден - DosError = 0, не найден, значит = 18... Не надо полагаться на содержимое SR в случае, когда файл не был найден. Произошла ошибка, это - все, что надо знать. Ошибка - значит, нет веры тому результату, который вернулся...

верно ли, что вызов FindClose(SR) прекращает поиск (работу с указателем) в директории расположения записи, а не в директории из последнего вызова процедуры FindFirst, поиск в других директориях не прекращается (непонятно, зачем вообще нужна эта процедура, если вся работа идет с данными из записи SR);

Директория расположения записи - это что? Запись располагается в памяти, если что... Терминология твоя ошибочна, задай вопросы с нормальной терминологией. И напиши, наконец, кусок кода, в котором у тебя получается не то поведение, которого ты ожидаешь... Не заставляй других угадывать, как это делал ты...

непонятно, зачем вообще нужна эта процедура, если вся работа идет с данными из записи SR

Ответ выделен:

FindClose frees any resources associated with the search record F.
This call is needed to free any internal resources allocated by the FindFirst or FindNext calls.

без выполнения данных взаимосвязанных утверждений рекурсивный поиск в директориях НЕВОЗМОЖЕН (по крайней мере, без создания списков их содержимого)

А мужики-то не знают, и уже десятки лет используют рекурсивный поиск в папках/подпапках... Если ты чего-то не осилил, не надо говорить, что это невозможно... В общем, пример, как пытался - в студию... Больше я догадываться не собираюсь... Будет код - будет разговор.

верно ли, что путь к директории в вызове процедуры FindFirst должен заканчиваться разделителем '\';

Первый параметр FindFirst - это маска имени файла, соответствие которой проверяется. И ничего больше.

что представляют собой неизвестные компилятору типы полей записи SR файла в директории под Win

Компилятору все прекрасно известно. Повторяю: эти функции используются не первый год, если что-то неизвестно - ошибку ищи у себя в коде, значит, неверно вызываешь... Телепаты с форума ушли...

Добавлено через 7 мин.
P.S.
То, чаво на белом свете, вообче не может быть! (по крайней мере - по твоему утверждению).

{$TELEPATHY ON}
P.P.S. Разницу между локальными и глобальными переменными хорошо понимаешь? Корень твоей проблемы - в этом...
{$TELEPATHY OFF}

9) верно ли, что записи в любой не изменившейся директории при каждой ее обработке процедурами FindFirst и FindNext выдаются в одном и том же порядке (лексикографическом по именам?);

Нет. Это зависит от ОСи, зависит от используемой файловой системы. Вот что по этому поводу говорит MSDN:

The order in which the search returns the files, such as alphabetical order, is not guaranteed, and is dependent on the file system. If the data must be sorted, the application must do the ordering after obtaining all the results.

Note In rare cases, file attribute information on NTFS file systems may not be current at the time you call this function. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function.

The order in which this function returns the file names is dependent on the file system type. With the NTFS file system and CDFS file systems, the names are usually returned in alphabetical order. With FAT file systems, the names are usually returned in the order the files were written to the disk, which may or may not be in alphabetical order. However, as stated previously, these behaviors are not guaranteed.

(отсюда: MSDN -> FindNextFile Function)