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

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

[TarasBer]

> На Дельфи пока рано переходить, весит больше, багов больше.

Да, семёрка в архиве 100 Мб. Но проблемы тут не вижу. Загружается она у меня не то, чтобы быстро, но терпимо, секунд 5. Да, я ставил минимальную версию (только добавил к ней помощь, исходники и редактор иконок).
Единственный баг в ней - это иногда пропадает ввод пробелов и всяких символов, тогда надо перезапускать. Случается это у меня в среднем раз в неделю.
В Паскале же бывают баги с неверным вычислением выражения, бывает, что ни с того ни с сего инвалид флоатинг поинт оператион (я уже знаю, что это стек сопроцессора переполняется, надо выражение в несколько этапов считать), а ещё из-за бесконтрольного доступа чего угодно к чему угодно баги в программе могут привести к каким угодно последствиям.

> Константное выражение, что нельзя?

Оно не константа, потому что оно не известно на этапе компиляции.

Сообщение отредактировано: TarasBer - 15.07.2010 13:44

[ddn]

Вот блин, под гостем оставил.
Там нужно исправить
f, d : file;
d заменить на g, постоянно всплывает этот старый идентификатор.
А еще диапазонный тип сделать без квадратных скобок.
Но отладчик выдает то же.

volvo, пару замечаний по вашей программе.
type идет после var, разве можно?
Там есть обработка исключений try finally, с ней никогда не работал.
Я так понял она просто делает переход на finally (раз except нет), если внутри блока возникла ошибка.
continue - фи, неструктурно!
e : boolean выбросить, в create_folder(dir2+sr.name+'\', sr.attr, sr.time) проставить dir_to_be_created.
Почему-то запуск fullcopydir('F:\T\', 'F:\G\', true) вне модуля program.

Вот там, где ты проверяешь, что в папку не было скопировано ни одного файла, и в зависимости от результата проверки B так сразу легко и просто удаляешь директорию, которая по твоему мнению - пустая (на данном уровне рекурсии файлы в нее не копировались). А что будет, если в ее дочернюю директорию копировались файлы (да и вообще, если текущая папка содержит подпапки), и ты попытаешься такую папку удалить через Erase? Кто вообще удаляет папки через Erase? Для этого придумали RD (оно же - RmDir).

Да, я и забыл про подкаталоги! Если обычный подкаталог найден, скопирован с содержимым и копия его не удалена, то после нужно поставить флаг b:=true. Придется сделать параметр-переменную и через нее передавать, что копия подкаталога не стерта.

Здесь надо действовать по-другому. Попробуй догадаться, как...

Нет, как раз не надо. Если в копии каталога есть скопированные подкаталоги, его удалять не надо - так и задумано.
Функция селекции одинаково проверяет и файлы, и каталоги (по атрибутам можно определить), каждый независимо от остальных. Любой каталог dir1, который даже не затребован селекцией, все равно копируется. Когда копирование его содержимого завершено, если в содержимом копии dir2 этого каталога есть файлы или каталоги (любого уровня вложенности), то и копия dir2 этого каталога не удаляется, даже если она сама отдельно не затребована (иначе куда девать содержимое этой копии). Только пустая копия должна удаляться, если она сама не требуется.

Неправда. При рекурсии это исправить проще простого. По крайней мере, гораздо проще, чем при итерации...

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

P.S. На всякий случай - копировать файлы побайтно - долгая история. В Хелпе Турбо Паскаля лежит пример использования BlockRead, так вот там приведена программа, производящее гораздо более быстрое копирование файла.

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

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

Да, верно.

В таком случае ЭТО - не Паскаль. По крайней мере, компиляторов, способных откомпилировать твой код, на данный момент не существует. Программа и подпрограмма (которая может принимать параметры) - это разные вещи. Учи язык, если хочешь с ним работать.

Сначала fullcopydir и была процедурой, потом, чтобы сделать ее работающей переделал в программу. Ведь procedure только декларирует, а исполняется только то, что в теле program. А про параметры я и не подумал.

Заглушка тоже должна компилироваться. Это компилироваться не будет. Ибо слова Return в Паскале нет.

Да, Return это в Модуле-2, и в Мапле.

Да, семёрка в архиве 100 Мб. Но проблемы тут не вижу.

На моем диске напряженка со свободным местом. А второй винт БП не тянет.

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

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

volvo, вашу он прокомпилировал - 134666 b.
В своей процедуре поставил {$mode delphi} {$I+, Q+, R+, S+} uses dos, sysutils, math после program;
заменил read(f, i) и write(g, i) на blockread(f, i, 1) и blockwrite(g, i, 1);
return(true) на sel := true;
поставил скобки в (i<=l) and (dir1[i]=dir2[i]),
и у меня тоже компилировал, наконец-то - 134494 b.