Столкнулся с новой для себя проблемой...

← →
Andy BitOff © (2005-11-29 20:28) [0]

... ну, не проблемой, а так, неожиданность. Век живи - век учись =)
Работает у заказчика моя программа, ну уже три года эксплуатации, все прекрасно. А тут.
Вообщем в программе создаются, в Temp"e несколько файлов, в которых содержится информация для последующей выборки. А читаются эти файлы, точнее список этих файлов как обычно FindFirst, FindNext и поскольку файлы создаются по порядку и имеют имена ввиде порядкового номера от 1 до N, то и алгоритм был завязан на том что в нужной строке (список файлов в сринглисте) находится имя нужного файла.
Так вот, стали поступать жалобы на то, что выборка делается не правильно, т.е. отображаются не те файлы, которые должны были бы. И это вдруг, ни с того ни с сего в отлично работающем алгоритме, при том, что на некоторых компьютерах программа отрабатывала, так же как и раньше.
Я мно-о-о-ого времени потратил на то, что бы выяснить в чем дело. И оказалось вот что. Не правильно работало на машинах на которых была NTFS. Оказывается FindFirst, FindNext возвращают на этой FS отсортированный список файлов, т.е. 1 потом 10 далее 100, потом 2 и т.д.
Вот такая неожиданная ошибка =)

← →
Anatoly Podgoretsky © (2005-11-29 20:44) [1]

Кто обещал конкретный порядок?

← →
Andy BitOff © (2005-11-29 20:49) [2]

Никто конкретно, но всегда так было.

← →
Джо © (2005-11-29 20:59) [3]

Никакой порядок в функции FindNext никогда и не кем не обещался. Ни в ДОС, ни в Виндовс, вне зависимости от ФС.

Яма была выкопана собственными руками. Комфортная, глубокая, основательная.
П.С. Я бы не называл это сомнительное мероприятие "алгоритмом". Сорри, ничего личного.

← →
Anatoly Podgoretsky © (2005-11-29 21:04) [4]

Andy BitOff © (29.11.05 20:49) [2]
Тебе просто везло.

← →
Andy BitOff © (2005-11-29 21:06) [5]

Докажите мне, дураку, что несколько файлов записанных в пустой каталог один за другим, функцией FindNext будут найдены в другой последовательности.

← →
Джо © (2005-11-29 21:07) [6]

> [5] Andy BitOff © (29.11.05 21:06)
> Докажите мне, дураку, что несколько файлов записанных в
> пустой каталог один за другим, функцией FindNext будут найдены
> в другой последовательности.

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 returned in alphabetical order. With FAT file systems, the names are returned in the order the files were written to the disk, which may or may not be in alphabetical order.
MSDN.

← →
Andy BitOff © (2005-11-29 21:07) [7]

Anatoly Podgoretsky © (29.11.05 21:04) [4]
Про везение в течении трех лет плотной эксплуатации, я думаю, говорить не приходится.

← →
Джо © (2005-11-29 21:09) [8]

Гм... невнимательно прочитал [5] Andy BitOff ©. Файлы все-таки пишутся в определенном порядке. Все-равно бы на это полагаться не стал.

← →
Andy BitOff © (2005-11-29 21:09) [9]

Джо © (29.11.05 21:07) [6]

Ну и...
Здесь как раз и подтвержаются мои слова.

← →
Piter © (2005-11-29 21:54) [10]

Andy BitOff © (29.11.05 20:28)
Оказывается FindFirst, FindNext возвращают на этой FS отсортированный список файлов, т.е. 1 потом 10 далее 100, потом 2 и т.д.

http://piter.pechora.org/temp/find_first.gif

← →
Piter © (2005-11-29 22:01) [11]

а-а-а, я не прочитал далее пост - да, на FAT файлы сортируются в порядке их создания. Видимо, из-за того, что в FAT таблице размещения файлов один файл за другим следует в порядке создания.

А вот на NTFS используются всякие индексные деревья и т.д. - там сама файловая система сортирует файлы по именам, вот, наверное, так и получается.

А алгоритм, конечно, непродуманный.

← →
Piter © (2005-11-29 22:02) [12]

Piter © (29.11.05 22:01) [11]
в FAT таблице размещения файлов один файл за другим следует в порядке создания

сам не понял :)

Имел в виду, что в FAT таблице имена файлов друг за другом идут в порядке создания.

← →
Винт (2005-11-29 22:05) [13]

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

← →
Lamer@fools.ua © (2005-11-29 22:11) [14]

Мне данная тема чем-то напоминает один топик на sql.ru, где один человек упорно не хотел писать в запросе ORDER BY, убеждая, что оный на фиг не нужен, ибо ему нужна сортировка как раз по тому полю, которое является первичным кластерным ключом (сервер MS SQL, если не ошибаюсь).

← →
Винт (2005-11-29 22:19) [15]

Lamer@fools.ua © (29.11.05 22:11) [14]

Маклай, ну автор-то не замечен в таковом;)

← →
Andy BitOff © (2005-11-29 22:22) [16]

Piter © (29.11.05 22:01) [11]
А алгоритм, конечно, непродуманный.

Алгоритм можно считать непродуманным, сейчас, а когда я его писал, три года назад, то мало знал про NTFS, да и стояла она мало где. У заказчика-то NTFS стала появляться месяц назад.

← →
Винт (2005-11-29 22:25) [17]

Andy BitOff © (29.11.05 22:22) [16]

Наверняка ведь используешь выделенную процедуру для поиска файлов?
Тогда изменение не будет затруднительным...

← →
Andy BitOff © (2005-11-29 22:30) [18]

Винт (29.11.05 22:25) [17]

Я не говорил, что трудно изменить, уже все работает как надо.
Я просто хотел поделиться =)

← →
Винт (2005-11-29 22:31) [19]

Andy BitOff © (29.11.05 22:30) [18]
Я просто хотел поделиться =)

Тогда тоже поделюсь.

Из-за того, что на NTFS есть дополнительные атрибуты у файлов и каталогов, в свое время долго искал глюк в своей программе при переходе с FAT на NTFS. и тоже в FindFirst.

← →
Джо © (2005-11-29 22:31) [20]

> Andy BitOff ©

А еще некоторые пользователи имеют привычку чистить Temp, причем никто им не запретит сие делать во время работы твоей программы. Не страшно было таким образом передавать параметры?.. ;>

← →
Andy BitOff © (2005-11-29 22:36) [21]

Джо © (29.11.05 22:31) [20]

=)

Ну так можно далеко зайти =)

А многие пользователи и не знают, что такое Temp.

← →
isasa © (2005-11-29 22:37) [22]

Piter © (29.11.05 22:02) [12]
Винт (29.11.05 22:05) [13]

Имена файлов в системе FAT нфходятся в DIR-разделе(для каждого каталога свой), а не в FATтаблице

Именуй 01.*, 02.*,... 09.*, 10.*, ... и все пройдет. (Если тысяча - 001...999)

← →
isasa © (2005-11-29 22:51) [23]

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

← →
Piter © (2005-11-29 23:15) [24]

Andy BitOff © (29.11.05 22:22) [16]

Да какая разница какая операционная система. Сам принцип того, что программа сама сохраняет данные в файл, а потом их извлекает для обработки - некорректен. Почему бы сразу не обрабатывать даннные?

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

← →
Piter © (2005-11-29 23:15) [25]

Piter © (29.11.05 23:15) [24]
Да какая разница какая операционная система

и файловая система.

← →
Andy BitOff © (2005-11-29 23:32) [26]

Piter © (29.11.05 23:15) [24]

Питер я не буду обсуждать здесь, что корректно, а что нет, для задачи о которой никто здесь не имеет никакого представления. А выкладывать ТЗ на 13 печатных листах у меня тоже желания нет.

Уверен, что при чуть большем коде ...
Код и так получился большой, основной модуль... сейчас посмотрю... 11074 строки, а их не один, правда не все таки =)

... можно было обойтись без всяких временных файлов.
Нет.

Я не просил ни у кого совета, Я ПРОСТО ПОДЕЛИЛСЯ НОВЫМ ДЛЯ СЕБЯ ФАКТОМ.

← →
Piter © (2005-11-30 00:02) [27]

Andy BitOff © (29.11.05 23:32) [26]
... можно было обойтись без всяких временных файлов.
Нет.

ты точно неправ. Можно было точно.

Andy BitOff © (29.11.05 23:32) [26]
Я не просил ни у кого совета, Я ПРОСТО ПОДЕЛИЛСЯ НОВЫМ ДЛЯ СЕБЯ ФАКТОМ

да факт то мы поняли.

Но ведь никто нам не мешает далее обсуждать, верно? :)
В том числе и твои алгоритмы, ты таки создал публичную ветку :)

> Да какая разница какая операционная система. Сам принцип
> того, что программа сама сохраняет данные в файл, а потом
> их извлекает для обработки - некорректен. Почему бы сразу
> не обрабатывать даннные?

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

Владислав © (30.11.05 7:51) [28]
И так поступает огромное количество общеизвестных приложений

да ладно? Пример в студию, пожалуйста.

> isasa © (30.11.05 17:31) [30]
> Piter © (30.11.05 17:09) [29]
>
> MS Word

Нука, попробуй удалить его временные файлы во время работы ;-)

Если чешутся руки, чего-нибудь удалть - иде по пути
temp=

2 Плохиш © (30.11.05 17:33) [31]

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

2 Piter © (30.11.05 17:09) [29]

любой инсталлятор именно так и делает

isasa © (30.11.05 17:31) [30]
MS Word

и где он сохраняет данные, чтобы потом их считать и проанализировать?

umbra © (30.11.05 17:52) [33]
любой инсталлятор именно так и делает

как именно он делает?

распаковывается в %TEMP%, оттуда копирует нужные файлы куда надо, затем из %TEMP% ненужное удалаяет (если сделан хорошо, может и не удалить). А Вы считаете, что весь инсталлятор должен в памяти сидеть?

Плохиш © (30.11.05 17:33) [31]
Так они правильно работают с файлами, чего не скажешь про другие программы. И поостерегу от удаление файлов из TEMP чрезвычайно опасно, подробности здесь http://podgoretsky.com/ftp/Language/nps/ru.delphi.html#N130
Душещипательная история

umbra © (30.11.05 19:24) [35]
распаковывается в %TEMP%, оттуда копирует нужные файлы куда надо

и что? У него смысл - распаковать файлы.

Во времена ЕС или 286 такое решение с писанием в файл еще приемлимо, но сейчас.... Мне кажется..... неосторожно (если она не держит их открытыми, но она их закрывает, иначе поиск был бы не нужен).

Piter © (30.11.05 18:44) [34]
и где он сохраняет данные, чтобы потом их считать и проанализировать?
Временный файл создается в каталоге открываемого документа.
Если документ криво закрыть, или снести Word с открытым документом - файл останется. Его (файл) можно увидеть проводником (имя, расширение то-же - первые два символа изменены на ~$ - атрибут - скрытый). Кроме того, создаются временные файлы в %TEMP% - каталоге.

Столкнулся с новой для себя проблемой... Найти похожие ветки