Нужно в папку сохранять файлы без участия юзера. То есть имя должно быть уникальным.
При переборе этих файлов при помощи FindNextFile нужно чтобы они находились в порядке обратном порядку их создания. При этом не свои (юзерские) файлы не нужны вовсе (я их фильтрую по содержанию). 

Какие будут идеи по поводу алгоритма выбора имен?

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

Есть такая идея: получать текущую дату и производить такие вычисления:

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

Может просто IntToStr(GetTickCount)+'.txt'? 

Yanis, не самый надежный способ.
И не удовлетворяет условию задачи.
Т.к. порядок получится вообще какой попало в зависимости от перезагрузки системы.
Вот так будет правильнее.

Добавлено @ 09:24 
Более поздние файлы должны идти по списку раньше.

Добавлено @ 09:25 
P.S. По дефолту, файндфёст будет находить файлы в порядке их создания, независимо от имени. 

да? хреново...
 

Ищи, добавляй в стринглист, сортируй - будет нужный результат.

Добавлено @ 09:41 
Как вариант - при добавлении нового файла, менять ему дату создания на более раннюю.
Но не факт, что поможет. Я не проверял. 

Знаю, просто подумал, что может для простой задачи и так пойдёт.

bems
Почему бы вообще не завести свой тип файлов? 

Именно так я и сделал. Ну а как это касается темы?

Добавлено @ 09:55 

В проекте SysUtils - роскошь, а ты про стринглист   

Я имею, что файлы юзера и файлы твоей программы пересекаются. Может можн как то разграничить? В отдельные папки например... 

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

Тогда просто создавай файл - список нужных тебе файлов. И чужие файлы в этот список уже никак не влезут... 

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

Ну с уникальностью ясно.
Вопрос с упорядочиванием файлов.
Тебе нужен последний созданный файл или список файлов, упорядоченных по дате создания?
Если первое, то просто беги файндфёстом и бери последний.
Если второе, то беги фаёндфёстом и организуй стек из имен файлов.
Потом для работы просто доставай из стека по одному. 

Клиент посылает проге дату последнего известного сообщения лога. В хедере файла есть начальная и конечная дата лога. Нужно передать клиенту информацию от текущей даты вниз до последней известной. Если искать в порядке убывания дат то будет значительно быстрее (считая что файлов сотни в пределе и нужно открывать для чтения каждыый в этом диапазоне)
 

Но построить стрек имен файлов ведь недолго.
Для этого их совсем не нужно открывать.
Кроме того, если в имени файла уже заложена дата, то не нужно открывать все - можно сориентироваться по имени или дате создания. 

Точно принадлежность файла можно определить только по сигнатуре в хедере - а вдруг чужой?

Добавлено @ 17:50 
И то не точно. Думаю добавить CRC
 

Зачем. Просто создай своё персональное расширение для своих файлов.
Например '5123482835.ItsFileOfMyCoolProgram'
Или в конце концов создай GUID и используй его, как собственное расширение.
Файлов с расширением A8D329BD7C8B4E1DB88F3876B602EF64 точно не бывает. 

Уже сделал.
Не бывает. А если глядя на мои юзер скопирует? И скажи что никто этим не займется!
 

Главное, что в стандартных условиях большинство файлов сразу отсеится.
А в нестандартных - юзер сам виноват.
Проверку нуно делать перед использованием конкретного файла.
Проверять все - незачем. 

Как бы ни ухищрялся, всегда найдётся изобретательный идиот, который сделает именно то, о чем ты не подумал.   
Проще в описании программы написать "в папке данных программы нельзя создавать / изменять / удалять / переименовывать файлы".  Никто ведь Биллу не дотумкается выставить счет, если при удалении случайных файлов пакета Microsoft Office, тот случайно перестанет работать.   

А защитить файлы можно просто раздачей прав на папку (NTFS rules).


Не знаю. Если бы меня попросили реализовать нечто подобное, я бы полностью абстрагировался от этих "изобретательных идиотов", и сделал бы диапазон дат лога в его имени. Типа 

ГГГГММДДЧЧММСС_ГГГГММДДЧЧММСС.MyExt

тогда бы поиск файлов был бы простым перебором всех имен.

Просто в этом случае нужно было бы проверять корректность системных часов (да хоть при запуске), чтоб не было запусков "в прошлом".

И уж если очень захотелось бы быть уверенным в целостности файла, то прикрутил бы к нему какой-нить хэш в конце (типа CRC, SHA1 etc, только чуть подкриптованных и измененных, чтоб отсеять и очень изобретательных идиотов   ) 

А юзеру эта прога и не нужна. Нужна она админу. Так что "юзер виноват" не оправдание

Используются на другой машине. Что, отправлять кучу лишнего, а там уже разбираться? Дорорговато...

Если моя прога перестанет работать юзер только обрадуется. Вот если бы тачку перезагрузить в случае глюков  

это отдельный разговор


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

Тогда нужно хэш тулить уже в имя файла.    Например, помимо даты/времени (с секундами) добавлять в имя рэндомное число, и хитрый хеш на эту часть имени. Тогда легко проверить имя валидно / нет, даже не загружая файл. 

Спасибо, ребята. 
Останавливаюсь на следующем:
 1. Файлы называются ггггммддччммссс.gsrtrs5ysrwrevthh.ext         где ггггммддччммссс время ПЕРВОГО сообщения в логе, а gsrtrs5ysrwrevthh выбирается во время сохранения
 2. Вхедере оставляю и время первого и время последнего сообщения.
 3. При чтении директории для выбора очередности обработки игнорирую все после первой точки
 4. Отправляю на тачку админа файлы, в имени которых есть дата и время после указанных в запросе клиентской части проги.
 5. Открываю файл, предшествующий по дате и времени (тех что в имени) первому отправленному и проверяю на частичное соответствие запросу. Если запрошенная клиентом дата где-то в середине этого файла, то отправляю и этот.

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

Это сообщение отредактировал(а) bems - 27.5.2006, 16:06

По какому принципу? И есть ли фильтрация по именам до открытия файлов и чнения хедеров?

Представим, я тупой юзверь, и запустил вот такую программу:


Админ асилит стока файлов? 

Просто нужно еще на стороне клиента проверять - правильный файл или нет. 

рандомно, пока ERROR_ALREADY_EXISTS   

да. ты ж сам предлягал дату в имя внести.



админ - не знаю, сетка - с трудом

само собой

  

Это сообщение отредактировал(а) bems - 27.5.2006, 17:35

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

Вот, накропал пример. Там использовал чуть измененный CRC32 - изменил сам полином, и начальное число. Плюс ещё данные XOR'ю ключом. Не думаю, что найдется у вас юзверь, что этот хаш сможет сгенерить без ковыринга в сорцах.   

Вот образцы валидных сгенеренных имен.
200605281950437127B0974C8.ext
2006052819505540079C9687D.ext
20060528195104150BF12C7CA.ext

А по ходу нашел забойную книжу! Советую всем, кто хочет в CRC разобраться
Ross N. Williams "Элементарное руководство по CRC алгоритмам обнаружения ошибок"

 

Присоединённый файл ( Кол-во скачиваний: 3 )
 FileNameValidator.zip 3,20 Kb

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

За книжку и исходник огромное спасибо. И плюс 

Нема за що. Тема просто интересная.  

Добавлено @ 21:25 
   (ну не удержался)


   У меня такое иногда после праздников бывает..