FindFirst-FindNext

← →
Anatoly P (2003-06-09 19:56) [0]

Есть ли альтернатива FindFirst-FindNext-у, а то замечена некорректная работа на NTFS под WXP?

← →
clickmaker © (2003-06-09 19:59) [1]

Нет. А в чем некорректность ?

← →
Anatoly P (2003-06-09 20:04) [2]

Возникает при работе с каталогом в котором лежит EXE-шник, лично сталкивался на двух компах, пока не понял в чем проблема

← →
TCrash © (2003-06-09 20:09) [3]

А при работе с другими каталогами все нормально ?
и в каком месте возникает пробдема?

← →
Anatoly P (2003-06-09 20:11) [4]

Проблема только при работе в каталоге EXE-шника

← →
TCrash © (2003-06-09 20:36) [5]

Что за проблема? при сканировании атрибутов какого файла?
Что-то я подозреваю, что только при чтении атрибутов exe-шника или dll-ок

← →
panov © (2003-06-09 20:45) [6]

FindFirstFile
FindNextFile

← →
Mystic © (2003-06-09 20:51) [7]

Привели код, который работает ошибочно

← →
Anatoly P (2003-06-10 12:50) [8]

Код тотже что в справке, только в Edit1.text путь, где лежит Exe-шник

← →
Юрий Федоров © (2003-06-10 12:58) [9]

Альтернатива - IShellFolder

Так мы и не узнаем, в чем заключается ошибка при FindFirst ??

← →
Palladin © (2003-06-10 13:05) [10]

А зачем нам знать?
Anatoly P признаный авторитет в области разработки приложений с максимальной плотностью ошибок, ему даже не нужно эту ошибку указывать, она точно есть, а вы дяденьки ищите думайте.

← →
Домарощинер © (2003-06-10 13:15) [11]

Довольно интересный подход к выбору ника.
Сразу напрашивается ассоциация - Anatoly P</p>odgoretsky.
Но насколько мне известны привычки последнего, ему не свойственно искать ответы подобным образом.

С Уважением.

← →
Anatoly P (2003-06-10 13:39) [12]

что-то Вы тут мутите, а с этим я сталкивался 2 раза.

← →
Игорь Шевченко © (2003-06-10 13:43) [13]

Anatoly P (10.06.03 13:39)

Код в студию!

← →
Anatoly P (2003-06-10 13:44) [14]

sss:=ExtractFileDir(Application.ExeName)+"\*.mye";
if findfirst(sss,FileAttrs, sr) = 0 then
repeat
if ((sr.Attr and FileAttrs) = sr.Attr) then
ComboBox1.Items.Add(sr.Name);
until FindNext(sr) <> 0;
FindClose(sr);

Вот код , до строки ComboBox1.Items.Add(sr.Name); не доходит

← →
Anatoly P (2003-06-10 13:45) [15]

Да еще, при переносе на диск c не NTFS, все работает как положено

← →
Юрий Федоров © (2003-06-10 13:48) [16]

а FileAttrs проинициализировать не забыл ?

← →
Игорь Шевченко © (2003-06-10 14:02) [17]

Anatoly P (10.06.03 13:44)

Мало кода

← →
panov © (2003-06-10 14:02) [18]

Так какая ошибка-то происходит?

Это что - засекреченная информация или насмешка над всеми?

← →
NailMan © (2003-06-10 14:12) [19]

if ((sr.Attr and FileAttrs) = sr.Attr) then
я всю сознательную программерскую жизнь не не видел чтобы сравнивали переменную модифицированную константой(опрератором and) c самой переменной. Обычно делают так:

if ((sr.Attr and FileAttrs) = FileAttrs) then

← →
Palladin © (2003-06-10 14:17) [20]

> NailMan © (10.06.03 14:12)

зря ты так...

← →
NailMan © (2003-06-10 14:40) [21]

To -> Palladin ©
Любите мучать? :-)

← →
NailMan © (2003-06-10 14:43) [22]

Но мне тоже интересно в чем заключалась "некорректная работа на NTFS под WXP" и как этот код работал на FAT32 и под win9x.

← →
sniknik © (2003-06-10 15:02) [23]

Anatoly P (10.06.03 13:44)
sss:=ExtractFileDir(Application.ExeName)+"\*.mye";
замени на
sss:=ExtractFileDir(Application.ExeName)+"*.mye";
и проверь
p.s.
"путь\\*.mye" не всегда находит, "путь\*.mye" всегда.

← →
Palladin © (2003-06-10 16:00) [24]

> sniknik © (10.06.03 15:02)

ExtractFileDir возвращает без \
ExtractFilePath возвращает с \

> NailMan © (10.06.03 14:12)

условие наисано корректно, FileAttr скорее всего не инициализирован или у него просто нет прав на эту директорию...

← →
Anatoly P (2003-06-10 16:06) [25]

Повторяю:

Проблема только при работе в каталоге EXE-шника

Да еще, при переносе на диск c не NTFS, все работает как положено

И никаких насмешек!

← →
Anatoly P (2003-06-10 16:08) [26]

Не выполняется строка: ComboBox1.Items.Add(sr.Name);

← →
Anatoly P (2003-06-10 16:10) [27]

> Palladin © (10.06.03 16:00) А как эти права раздобыть? Скорее всего проблема в этом

← →
Palladin © (2003-06-10 16:13) [28]

в свойствах папки смотри Permissions и
наконец покажи код выше строки
sss:=ExtractFileDir(Application.ExeName)+"\*.mye";
где у тебя FileAttr инициализируется!!

← →
Anatoly P (2003-06-10 16:15) [29]

ComboBox1.Clear;
FileAttrs:=faAnyFile;

Вот оно! И все

← →
Игорь Шевченко © (2003-06-10 16:18) [30]

Anatoly P (10.06.03 16:15)

Дружище, мой тебе совет: возьми в руки отладчик, посмотри, что происходит при работе твоей программы в разных случаях и нам потом расскажи. Интересно ведь:))

FindFirst/FindNext отлично работают в WinXP в ЛЮБОМ каталоге, будь то каталог exe"шника или другой. Доказано Zanussi.

← →
Юрий Федоров © (2003-06-10 16:21) [31]

Обрати наконец внимание на
NailMan © (10.06.03 14:12)

← →
Palladin © (2003-06-10 16:22) [32]

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

← →
Anatoly P (2003-06-10 16:24) [33]

У меня дома XP - и никаких проблем, у клиента XP и когда программа лежит на диске с FAT - никаких проблем, а на NTFS, то о чем говорил
> Игорь Шевченко © (10.06.03 16:18) - Смотрел - обходит злополучную строку.

ЗЫ: В принципе для меня это не проблема - ведь есть и раздел с фат, но все же. Когда-нибудь столкнетесь - вспомните!

← →
Anatoly P (2003-06-10 16:26) [34]

> Palladin © (10.06.03 16:22)
sss:=ExtractFileDir(Application.ExeName)+"\*.mye";
Хоть убей, не перепутал

← →
handra © (2003-06-10 16:31) [35]

Anatoly P (10.06.03 16:15)
ComboBox1.Clear;
FileAttrs:=faAnyFile;

Вот оно! И все
Таким образом ищутся папки (они же метки тома) с аттрибутами ReadOnly+System+Hidden, имеющие имя с маской "*.mye"! Вероятность их существования равна нулю ;)

← →
handra © (2003-06-10 16:32) [36]

хотя нет, погорячился...

← →
Мое имя (клоны все равно суксь) (2003-06-10 16:32) [37]

> Palladin © (10.06.03 13:05)

;))))))))))

> NailMan © (10.06.03 14:12)

> я всю сознательную программерскую жизнь

значит на самом деле то была матрица...)))))))
что плохого в выражении if (i*1=i) ? ;-)

← →
Игорь Шевченко © (2003-06-10 16:34) [38]

Anatoly P (10.06.03 16:24)

А почему обходит-то, расскажи, не стесняйся :) Чему равны значения, которые ты проверяешь в условии в одном и в другом случае ? Не молчи, партизан ты наш :))

← →
Юрий Федоров © (2003-06-10 16:42) [39]

> NailMan © (10.06.03 14:12)
Блин, запутал... И я повелся :-)

← →
Sandman25 © (2003-06-10 16:44) [40]

По-моему, единственное объяснение - не выполняется условие if.

Constant Value Description
faReadOnly $00000001 Read-only files
faHidden $00000002 Hidden files
faSysFile $00000004 System files
faVolumeID $00000008 Volume ID files
faDirectory $00000010 Directory files
faArchive $00000020 Archive files
faAnyFile $0000003F Any file

То есть в NTFS у найденного файла установлены не только младшие 6 бит установлены, но еще установлены какие-то старшие биты. И естественно при проверке $010000xx and $3f мы получаем $000000xx, что не равно исходному $010000xx.
Уберите проверку - она все равно не нужна.

← →
Игорь Шевченко © (2003-06-10 16:57) [41]

Sandman25 © (10.06.03 16:44)

Единственное объяснение даст выполнение под отладчиком и просмотр значений непосредственно при выполнении проверки. Иначе это гадание на кофейной гуще - а оно нам надо ? :))

← →
sniknik © (2003-06-10 17:12) [42]

Sandman25 © (10.06.03 16:44)
выполняется. $010000xx and $3f = $000000xx и сравнивается с $000000xx

т.к. являюсь счастливым обладателем диска с разделами разбитыми и под FAT32 и под NTFS решил проверить
собрал весь код из приведенных, частей

procedure TForm1.Button1Click(Sender: TObject);
var sss: string;
sr: TSearchRec;
FileAttrs: Integer;
begin
FileAttrs:= faAnyFile;
sss:= ExtractFileDir(Application.ExeName)+"\*.pas";
if findfirst(sss,FileAttrs, sr) = 0 then
repeat
if ((sr.Attr and FileAttrs) = sr.Attr) then ComboBox1.Items.Add(sr.Name);
until FindNext(sr) <> 0;
FindClose(sr);
end;

могу заверить, в FAT32 и NTFS работает одинаково. система W2k

← →
Anatoly Podgoretsky © (2003-06-10 17:46) [43]

Anatoly P (10.06.03 13:44)
Доходит, но не всегда, а в очень редких случаяз, только тогда когда sr.Attr = FileAttr
Налицо резкое непонимание работы оператора AND и аттрибутов файла.

← →
Anatoly Podgoretsky © (2003-06-10 17:51) [44]

Знакомый код, вроде бы был опубликован в каком то Чаво и теперб многие переносяю этот абсурд в свои программы, абсолютно не думая головой, а что же они делают

if ((sr.Attr and FileAttrs) = sr.Attr) then
ComboBox1.Items.Add(sr.Name);

← →
Sandman25 © (2003-06-10 17:54) [45]

Anatoly Podgoretsky © (10.06.03 17:46)

Нет. Мы сравниваем $xx and $3F с $xx - получается true для любого $xx <= $3F.

← →
Sandman25 © (2003-06-10 18:01) [46]

Другое дело, что FindFirst/Next и так нам возвращает файл с указанными атрибутами, даже если FileAttr не равно faAnyFile. Зачем еще раз на них проверять, контролируя Windows?

← →
Юрий Федоров © (2003-06-10 18:41) [47]

Anatoly Podgoretsky © (10.06.03 17:51)
Это не Чаво, это Help по delphi :-)

← →
Игорь Шевченко © (2003-06-10 18:51) [48]

Юрий Федоров © (10.06.03 18:41)

Точно! :) Осталось выяснить у автора вопроса, что же все-таки отладчик показывает :)))

← →
Юрий Федоров © (2003-06-10 19:02) [49]

>>Игорь Шевченко © (10.06.03 18:51)
Думаю, это то самое мистическое и тайное знание, которого нам не суждено постичь :-)

← →
Anatoly P (2003-06-10 19:37) [50]

Я бы ответил, но на тех компах нет Delphi. А на домашнем как у всех уважаемых мастеров - нет проблем. Ну вот появился Anatoly Podgoretsky , появляется надежда.

← →
sniknik © (2003-06-10 19:54) [51]

на моем примере см. выше отладчик кажет (при сравнении)
sr.Attr=32 FileAttrs=63
итого
((32 and 63) = 32) = True

то же самое в столбик
0100000 - 32
0111111 - 63
and
0100000 - 32
=
0100000 - 32
yes!

Anatoly P (10.06.03 19:37)
> Я бы ответил, но на тех компах нет Delphi.
а ты добавь мемо на форму и делай в него лог интересующих переменных, с маркерами где произошло.

← →
Anatoly P (2003-06-10 19:55) [52]

Завтра проверю. Спасибо

← →
Anatoly Podgoretsky © (2003-06-10 20:00) [53]

Sandman25 © (10.06.03 17:54)
Нет. Мы сравниваем $xx and $3F с $xx - получается true для любого $xx <= $3F.

Нет, мы сравниваем sr.Attr and что то c sr.Attr, а надо бы sr.Attr and что то c что то, в этом и есть ошибка или точнее абсурд, если бы нас интересовали биты за пределами $3F то и надо бы было их проверять.
Я так понимаю, что эти биты как раз не интересуют. А этот код я уже не раз видел. В хелпе действительно такой пример и что они этим хотели сказать не понятно, наверно пытались запутать.

← →
han_malign © (2003-06-10 20:12) [54]

есть еще атрибуты
FILE_ATTRIBUTE_NORMAL = $00000080;
FILE_ATTRIBUTE_TEMPORARY = $00000100;
FILE_ATTRIBUTE_COMPRESSED = $00000800;

>но на тех компах нет Delphi
- логи - великая вешь, моя текущая задача, в отладке, за час до 5Mb логов пишет, причем режим отладки включается/выключается на лету...

← →
nikkie © (2003-06-10 20:21) [55]

многие здесь почудили...

>Anatoly Podgoretsky
>Нет, мы сравниваем sr.Attr and что то c sr.Attr, а надо бы sr.Attr and что то c что то, в этом и есть ошибка или точнее абсурд
это как раз сравнение (sr.Attr and что то c что то) будет абсурдом. поскольку это что-то - faAnyFile.

← →
Anatoly Podgoretsky © (2003-06-10 20:30) [56]

Нет проблема не с левой частью, а с правой.
Скажем нормально будет
(sr.Attr and faDorectory) = faDirectory
или даже
(sr.Attr and faAnyFile) = faAnyFile

А вот
(sr.Attr and faDirectory) = sr.Attr
(sr.Attr and faAnyFile) = sr.Attr
это что то, кроме особых случаев, особенно на NTFS

← →
nikkie © (2003-06-10 20:32) [57]

Логика в примере из хелпа некоторая есть: если снят флажок "hidden", то hidden файлы показваться не будут, если снят флажок "directory", то не будут показываться и директории.

Однако, это не означает, что если флажок "directory" стоит, то будут показаны все директории.

Так что с точки зрения кодировщика там все в порядке, а с точки зрения организации пользовательского интерфейса - то, как не надо делать.

← →
nikkie © (2003-06-10 20:43) [58]

>Anatoly Podgoretsky
(sr.Attr and faDorectory) = faDirectory
это нормально, я согласен. а вот
(sr.Attr and faAnyFile) = faAnyFile
имхо, это всегда FALSE.

← →
sniknik © (2003-06-10 22:46) [59]

Anatoly Podgoretsky © (10.06.03 20:30)
> Нет проблема не с левой частью, а с правой.
> Скажем нормально будет
> (sr.Attr and faDirectory) = faDirectory //точно нормально
> или даже
> (sr.Attr and faAnyFile) = faAnyFile //чуш, никогда не сработает sr.Attr никогда не равен всем ключам сразу

> А вот
> (sr.Attr and faDirectory) = sr.Attr //нормально, директории
> (sr.Attr and faAnyFile) = sr.Attr //нормально, любой тип
> это что то, кроме особых случаев, особенно на NTFS

вобще единственное почему такое условие может не сработать это если sr.Attr >= 64 (c faAnyFile). (а дело может быть совсем в другом)
Anatoly Podgoretsky © а вы неправы и настаиваете. проверьте сами.

написал почему может не сработать условие (sr.Attr >= 64), но вроде такого нет но решил убедится.
и удивился D7 модуль SysUtils константы

{ File attribute constants }

faReadOnly = $00000001 platform;
faHidden = $00000002 platform;
faSysFile = $00000004 platform;
faVolumeID = $00000008 platform;
faDirectory = $00000010;
faArchive = $00000020 platform;
faSymLink = $00000040 platform;
faAnyFile = $0000003F;

а ведь может, и не сработать. что это за тип такой? из Linux-a чтоли? в хелпе по findfirst не упоминается наоборот в Linux нет
"Some of the file attribute constants are not valid on all platforms. For example, faVolumeID and faArchive will not work on Linux."
в общем если это виндовый новый атрибут то может и не сработать.

faSymLink = $00000040 platform;

Возможно, что это
Hard Link - в NTFS 5.0
или Junction Point (точки соединения)

panov © (10.06.03 23:41)
т.е. всетаки из виндов (возможно)
но тогда ЭниФайле уже не Эни.. и надо поправить
faAnyFile = $0000007F; для полного соответствия.

Согласен с panov © (10.06.03 23:41), т.к. указанные вещи сами по себе имеют атрибуты больще $3F, сделай так :
if (sr.Attr and $FF)=srAttr then

Кстати в языке Clarion константа AnyFile Равна именно $FF.
ЗЫ : Clarion - это тот же С только выглядит по-другому, а результирующий код - тот же. Винда на чем писана ?

>sniknik
>тогда ЭниФайле уже не Эни..
эт-то точно.

>и удивился D7 модуль SysUtils константы
из WinNT.h от VC:
#define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_DEVICE 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 #define FILE_ATTRIBUTE_ENCRYPTED 0x00004000

>TCrash
>сделай так :
>if (sr.Attr and $FF)=srAttr then
могу предложить еще усовершенствовать этот код. вот так
if sr.Attr=sr.Attr then
или вот так
if True then
или вообще выкинуть, что АП сразу предлагал...

>ЗЫ : Clarion - это тот же С только выглядит по-другому,
знаем мы, что такое Clarion, не надо нам баки забивать...
а результирующий код - тот же. Винда на чем писана ?
ну уж не на кларионе. зуб даю.

Я не это предлагаю, а следующее
if (sr.Attr and faDirectory)=faDirectory then
например для детектирования любых каталогов, и READONLY и HIDDEN и SYSTEM и ARCHIVE
Суть именно в правой стороне.

В самом вызове FindFirst указать аттрибуты faAnyFile и если есть подозрение, что не вернет записи с расширенными аттрибутами, то $FFFFFFFF с учетом даже дальнейшего увеличения их, но вроде бы и так вернет все записи.

> TCrash © (11.06.03 00:19)
> ЗЫ : Clarion - это тот же С только выглядит по-другому,
> а результирующий код - тот же. Винда на чем писана ?

А Паскаль - тот же Фортран, только выглядит по-другому. И результирующий код одинаковый, уверяю.

Anatoly Podgoretsky ©

Хорошо, убедили :)

Если нужно проверять на конкретный атрибут, то нуждо делать
if (sr.Attr and faDirectory) > 0 then
if (sr.Attr and faHidden) > 0 then
и т.д.

Если же у нас в маске поиска стоит "множество" атрибутов, как в примере, и нас интересуют только те файлы, в которых есть ВСЕ атрибуты из множества, то нужно делать именно так, как Вы написали.

Mask := faDirectory or faHidden;
FindFirst(..);
if sr.Attr and Mask = Mask then

Если же у нас в маске поиска стоит "множество" атрибутов, как в примере, и нас интересуют те файлы, в которых есть ХОТЯ БЫ 1 атрибут из множества, то нужно делать иначе.

Mask := faDirectory or faHidden;
FindFirst(..)
if sr.Attr and Mask > 0 then

Если же нам нужны только те файлы, в которых есть ХОТЯ БЫ 1 атрибут из множества и НЕТ таких атрибутов, которых нет в маске, то нужно делать так.
Для поиска скрытых директорий, для которых не установлен атрибут "архивный", не установлен атрибут "системный" и т.д.

Mask := faDirectory or faHidden;
FindFirst(..);
if sr.Attr = Mask then

А пример из Delphi help (if sr.Attr and Mask = sr.Attr then) имеет следующий смысл - нам нужно найти файл, в атрибутах которого нет ничего, чего не было бы в маске. При этом нас совершенно не волнует, есть ли у файла те атрибуты, которые есть в маске. То есть на самом деле мы задаем "отрицательную" маску - маску того, что нам не надо. Если мы не включили faHidden, значит, нужно исключить из рассмотрения все скрытые файлы и т.д.
Долой пример из Delphi help, ибо это плохой пример :)

Ошибся.

Если же нам нужны только те файлы, в которых есть ВСЕ атрибуты из множества и НЕТ таких атрибутов, которых нет в маске, то нужно делать так.
Для поиска скрытых директорий, для которых не установлен атрибут "архивный", не установлен атрибут "системный" и т.д.

Mask := faDirectory or faHidden;
FindFirst(..);
if sr.Attr = Mask then

Хотя если подумать, то получается, что пример из Delphi help не такой уж и плохой. Если мы не включили в маску faHidden и faDirectory, то значит, нам нужно все, кроме тех файлов, для которых эти биты установлены...

← →
Anatoly P (2003-06-11 12:57) [71]

Без проверки кстати работает (на XWP и на NTFS). Интересно что будет на W9x и W2000.
Насчет логов, такой результат:
File: english.mye sr.attr: 000000000002020Fileattr: 00000000000003F
File: russian.mye sr.attr: 000000000002020Fileattr: 00000000000003F

Делал так: Memo1.Lines.Add("File: "+ sr.Name+" sr.attr: "+ IntToHex(sr.Attr,15)+"Fileattr: "+ IntToHex(FileAttrs,15) );

>000000000002020
как раз чисто NTFS-ный флажок FILE_ATTRIBUTE_NOT_CONTENT_INDEXED (выключено индексирования для файла,папки или тома)
а коснтанты faXXX введены только для добавления в фильтр поиска не добавляюмых по умолчанию файлов(каталогов) и проверки принадлежности очередного к ним(см. Anatoly Podgoretsky ©), а реальный атрибут возвращеется конкретно системный (GetFileAttributes,Find{First/Next}File - TWin32FindData.dwFileAttributes)

function FindMatchingFile(var F: TSearchRec): Integer; var LocalFileTime: TFileTime; begin with F do begin while FindData.dwFileAttributes and ExcludeAttr <> 0 do if not FindNextFile(FindHandle, FindData) then begin Result := GetLastError; Exit; end;//пропускаем лишнее(см. ниже) FileTimeToLocalFileTime(FindData.ftLastWriteTime, LocalFileTime); FileTimeToDosDateTime(LocalFileTime, LongRec(Time).Hi, LongRec(Time).Lo); Size := FindData.nFileSizeLow; Attr := FindData.dwFileAttributes; //нате получите атрибут со всеми левыми флагами Name := FindData.cFileName; end; Result := 0; end; function FindFirst(const Path: string; Attr: Integer; var F: TSearchRec): Integer; const faSpecial = faHidden or faSysFile or faVolumeID or faDirectory; begin F. ExcludeAttr := not Attr and faSpecial;//вот такой изврат F.FindHandle := FindFirstFile(PChar(Path), F.FindData); if F.FindHandle <> INVALID_HANDLE_VALUE then begin Result := FindMatchingFile(F); if Result <> 0 then FindClose(F); end else Result := GetLastError; end; function FindNext(var F: TSearchRec): Integer; begin if FindNextFile(F.FindHandle, F.FindData) then Result := FindMatchingFile(F) else Result := GetLastError; end;

паритесь ...
Открою тайну, XP здесь не причем, зато причем NTFS.
Папка может иметь атрибут faSymLink = $00000040 и не иметь атрибут faDirectory = $00000010;

В общем, не знаю я почему так, но ВСЕГДА используйте только такую конструкцию:

if ((sr.Attr and SysUtils.faDirectory) <> 0) then
begin
ShowMessage("Ура я нашел файл с нужным атрибутом !")
end;

Игорь Шевченко © (10.06.03 16:57)

Вот видите - даже гадая на кофейной гуще, можно найти единственное возможное объяснение :)

← →
Anatoly P (2003-06-11 15:51) [76]

nikkie © (11.06.03 01:23) натолкнул(а) на мысль и решил проверить, оказывается все просто - на этих двух компах была отключена служба индексации на том разделе, где стояла прога. Но все равно не ясно, почему с другими каталогами нет проблем

И я это говорил, а мне не верили ;-)

Anatoly Podgoretsky © (11.06.03 16:13)

В данном конкретном случае - нет.
В маске было faAnyFile, то есть faHidden + faDirectory + faSystem и т.д.
"Ваше" условие бы сработало только в том случае, если у файла установлены ВСЕ эти атрибуты. В то время как "физический" смысл faAnyFile - атрибут может быть любым. Даже для файла с атрибутом $00000000 if должен был срабатывать.

И он срабатывал, если у нас sr.Attr and faAnyFile = sr.Attr (0 and $3F = 0)
И НЕ срабатывал, если у нас sr.Attr and faAnyFile = faAnyFile (0 and $3F <> $3F).
Убедил?

Не знаю только в чем, в первом случае будет срабатывать если не изменится ни один бит в sr.Attr (биты за пределами $3F будут сброшены, а для этого достаточно проверить sr.Attr and not $3F = <> 0, поскольку младчшии 6 бит просто не интересует, но врядли его интересовал вопрос установлены ли расширенные биты), а во втором случае если после операции AND останется $3F (такая комбинация вроде бы не возможно и предназначена для поддержки длинных имен, то есть поиском не выдается, даже если ее напрямую установить в записи каталога).

Для меня нет вопросов по работе с аттрибутами, начальная математика по работе с битами.

Насколько я понял, мы с Вами можем согласиться только в том, что проверку на faAnyFile проводить не имеет смысла.
А для проверок на что-то другое нужно знать, что же конкретно требуется в постановке задачи.

Ну тогда еще раз, если цель проверки определить установлен ли хоть один из расширенных битов (старшие 26 битов), то приведенная авторам конструкция верная, иначе налицо не понимание работы. На младщии 6 бит влияния не оказывается и маска указана верная.

Да, абсолютно согласен.

FindFirst-FindNext Найти похожие ветки