Привет всем!

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

Ну кто нибудь помогите плизз.. аа??

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

Ну насчет драйвера, было бы конечно хорошо, но пока слишком круто для меня, я еще маленький и неопытный программер, мне только 14 )

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

Это сообщение отредактировал(а) aMiGo! - 14.4.2003, 14:12

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

To Step:
а где эту инфу взять

книги такие были ИБМ пс АТ ХТ для пользователей, там много прикольного было, но на фате не зацикливайся - это слишком сложно

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

aMiGo! так порпбуи в один фаил записавать местополоэние фаилов и с того одного считавать в масив строку котораиа будет открывать тебе нужныи фаил а там с ним што хочеш делаж....

мы тебе тут насоветовали, а ты решай как решать проблему....

фатом можно, но это сложно, хотя есть рад приимуществ, по удалению и добавлению файлов в общий файл

да уж совет за советом а ничего толком почти здесь и нету....

сдесь есть все, просто надо не линиться думать

ето тоэ правда.... но он может и недадумать как тугадум можт попадется

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



можно не додумать если только программировать не уметь

я не просебя гоборю вообсче то....

да я тебя понял\, я тоже не про тебя я в общем

океы

tak voobsche v chom programirujesh eto dlja tebja Step a neznajesh kde mozhno skachat' Watcom C++ 11

я в визуале, не знаю
и давай наверное флейм в этом разделе заканчивать

даваи........

Будь проще. Используй базу данных. Файлы пиши в мемо-поля. Сейчас они позволяют держать там довольно внушительную по размеру информацию. Дополнительную информацию по этим файлам можно держать в дополнительных полях.

Проще тогда уж хранить отдельно кучку файлов и не искать проблем на свою голову.
Сначала надо выяснить почему такое нестандартное решение потребовалось. А то он напишет новый клон HalfLife для работы которого требуется MS-SQL вот смеху то будет.

в натуре, зачем это тебе надо

DENNN, не наезжай на HL! Я давно не встречал подобных игр.
M.E.G.U.S, Watcom проще купить на раскладке. А зачем он тебе? В нем же трудно асм вставки делать - такой гимор, что думал крыша съедет пока пытался замутить кое-что.

Не наезжаю я на HL - самому нравится. А наезжаю на тех, кто считает достойным делом качать исходники квака, компилить и показывать знакомым со словами "вот какой я крутой программер". А HL к слову пришлось - там есть файл *.mix мегов на 550 в котором все сцены и запиханы. Явно там подобная проблема решена. Не трудно догадаться зачем

Так сцены-то никто не редактирует - там проще (создать mapfile и мапить только те сцены, что нужно) и скорость отличная и не надо перебирать файлы на диске для поиска нужной сцены.
А тут задача - чтобы данные можно было бы после изменения - впихнуть обратно, причем размер их может варьироваться! Самый простой вариант - каждый файл отдельно хранится. Чуть сложнее - таблица с блобами.

Дались вам эти таблицы! Из-за такой мелочи жестко привязываться к серверу БД мягко говоря не самый лучший выход.
Если размер файла увеличивается, записать его в конец и все содержимое файла "подвинуть" чтоб неиспользуемого пространства не было. Не обязательно такую "дефрагментацию" делать сразу, можно либо в фоновом режиме, либо при превышении некоторого порога. Все равно ведь он фат заново не изобретет, а уже имеющийся прикрутить тоже не такое уж легкое дело.

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

Так, теперь ответы:

To DENNN: Ну, что касается ассем, то я сказал, мне только 14, я еще не очень опытный программер и кроме С++ и Паскаля, я почти ничего не знаю.. какой уж там ассемблер.

To M.E.G.U.S: Ну за тугАдума тебе спасибо, а за ответы спасибо // а пишется-то тугодум

To Step: ВАаще биг спасибо за такие полезные и умные ответы.

To Vyacheslav: Ну твой способ решения этой задачи весьма извращенный, мне такой не подходит, а так спасибою.

To ALL: а ваащето ясного ответа на мой вопрос я здесь не нашел..

Цитата

Ну, что касается ассем, то я сказал, мне только 14, я еще не очень опытный программер и кроме С++ и Паскаля

То что я предлагал, легче всего реализовать на C. Почитай функции работы с файлами. Если скорость не критична, то можно даже на MFC CFile и т.п. ......

aMiGo!, уточним задачку. Тебе надо именно в одном файле хранить или это не существенно?
Не хочешь ли оставить файлы как есть и создать один файл-описание, к-й хранит путь к каждому файлу и различную информацию о нем. Так ГОРАЗДО ПРОЩЕ для начинающего...

Цитата

To Step: ВАаще биг спасибо за такие полезные и умные ответы.

это ты в каком смылсе

To Step:

Цитата

это ты в каком смылсе

Я не куда не смылcе )
а в прямом..!

To man2002ua:
Нет, мне нужно, чтоб все файлы хранились в одном. Вся фича в том, что я делаю прогу установки WayPoint'ов к ботам. Там задаешь один файл (допустим "waypoints.dat" ), и он чиает все, что там внутри этого файла есть.
А что касается

Цитата

Не хочешь ли оставить файлы как есть и создать один файл-описание, к-й хранит путь к каждому файлу и различную информацию о нем.

, то нет, так слишком легко и неинтересно и, как мне кажется, неграмотно.

To man2002ua

Цитата

Так ГОРАЗДО ПРОЩЕ для начинающего...

Я не опытный, но не НАЧИНАЮЩИЙ. С++ изучаю уже год!
Для меня понятие начинающий означает ЛАМЕР, и я вообще это обидно.

Это сообщение отредактировал(а) aMiGo! - 18.4.2003, 21:01

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

Цитата

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

бери мою

Последний вопрос - данные (файлы) в таком файле будут иметь разную длину или постоянную?

Цитата

бери мою

Так дай мне свою )

Цитата

Последний вопрос - данные (файлы) в таком файле будут иметь разную длину или постоянную?

Конечно разную!

Значит делаем как сказал DENNN.
Файл будет состоять из структур таких:
typedef struct TChunk{
DWORD nOffset; // Смещение до следующего блока
BOOL IsFree; // свободный блок или нет
DWORD szBlock; // размер блока за структурой;
DWORD szFile; // размер данных в блоке
}TChunk, *LPChunk;

Ну, а управлять этим будет так:
- ищем свободный (IsFree) блок подходящего размера для помещения туда нашего файла (если блоков нет или их szBlock меньше нашего файла, то создаем в конце базы новый блок TChunk) или занимаем первый подходящий;
- плюс процедура оптимизации этой базы - удаление неиспользуемых блоков и ресайз других...

понятно? Почти как в Оракле.

ман2002уа ну я хотел попробовать што за черт етот Wатцом Ц++ е меня его нету плохавато а покупать нехочется....

аМиГо!ну за тугодума тогда извини.......... :/

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

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

еще как вариант поищи в инете исходники архиваторов и получишь готовый код объединяющий несколько файлов....

To man2002ua

Огромное тебе спасибо, идею я почти понял, но реализовать ее будет весьма трудно [для меня],
только я не совсем понял зачем нам искать свободный блок, ведь мы будем писать в конец файла.. аа постойка, все Ура! врубился.. Но конечно написать мне все это будет весьма затруднительно.

To M.E.G.U.S
Да я особенно и не обижался

To HexoGenus
Твоя идея мне очень понравилась, но конечно хотелось бы сделать все это самому, если сам не сделаю воспользуюсь твоим способом, теболее в любой Винде уже есть встроенные архиваторы типа ZIP и ARJ.

Цитата

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

Хорошо, больше так не буду, извиняюсь.. $$$

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

Код

int WriteBlock(const void *lpBuffer) {          HANDLE hFile;          DWORD nWriteBytes;          const char *lpFileName = "C:\\temp.txt";          hFile = CreateFile(lpFileName,GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,(void*)NULL);          if ((!hFile) || (hFile == (void*)0xffffffff))          return 0;          WriteFile(hFile,lpBuffer,strlen((char*)lpBuffer),&nWriteBytes,0);          CloseHandle(hFile);          return nWriteBytes; }

.....
//дальше пишу...

Код

for (int i = 0;i<=3;i++)  {   WriteBlock("Hello World!");  }

//По-моему, содержимое файла C:\\temp.txt должно выглядить так:
/*
Hello World!
Hello World!
Hello World!
*/
но в файле оказывается только одна строка - "Hello World!"

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

Цитата

CreateFile(lpFileName,GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,(void*)NULL);

CREATE_ALWAYS должно быть OPEN_ALWAYS иначе он перезапишет созданный ранее файл.
И лучше сразу оформляй это все в отдельный класс.

Спасибо DENNN, просто я ступил.

Ой, ой - всеравно не работает! (((
100% все сделал так.
Что делать-то!

Блин!! SetFilePointer на конец файла ставь!
Почему, то что я предложил сложно? Ты же год пишешь и апи владеешь?

Давай сделаем так: будут два файла, один собственно база с файлами, а второй каталог с именами и длинами этих файлов. Создавай сразу структуру и в файл пиши ее.

To man2002ua:

Цитата

Блин!! SetFilePointer на конец файла ставь!

Странно, я всегда без нее ообходился и все прекрасно работало.

Цитата

Почему, то что я предложил сложно? Ты же год пишешь и апи владеешь?

Да, я изучаю С++ уже год, но это не значит, что я сижу целыми днями за компом и пограммирую.. помимо этого я хожу в школу, делаю уроки и играю на компе в игрушки. Свободного времени на программирование остается не так уж много, это вы - программеры целыми днями сидите на работе за компами и пишите разные проги. К тому же я сомневаюсь, что все вы за год освоили C++.
А что касается апи, я не говорил, что я им владею, так, кое-что знаю.

З.Ы Без обид, надеюсь.

To DENNN

Цитата

Давай сделаем так: будут два файла, один собственно база с файлами, а второй каталог с именами и длинами этих файлов. Создавай сразу структуру и в файл пиши ее.

Нее.. сначала я попробую как сказал man2002ua, а если не получится, то буду делать по идее HexoGenus'a с архиваторами, либо как сказал ты.

Цитата

Нее.. сначала я попробую как сказал man2002ua,

Это как раз именно тот случай. Только читать струтуры из отдельного файла я думаю тебе намного лгче, чем искать эту же область в одном большом файле.
А насчет архиватора, то тут есть не сразу заметные недостатки. Такую систему, как пытаешся создать ты имеет смысл использовать когда у тебя множество больших и не очень файлов ( к примеру звуки и видео вставки к игре). Естественно общий объем таких файлов будет как минимум 150~300 МБ. Представь сколько пользователю придется смотреть на пустой экран прежде чем твое приложение все распакует и запустится. Это понятно. Но есть еще другие нюансы, такие как: если на жестком диске, куда будут распаковываться файлы не хватит свободного места, программа просто не запустится, высокая дефрагментация диска при каждом запуске проги, куда распаковывать файлы? в свою папку или каталог TEMP виндов?

aMiGo!, игрушки мне не враги

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

Это сообщение отредактировал(а) man2002ua - 21.4.2003, 14:38

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

Вы согласны с таким вариантом, или есть какие-то нюансы?

А так огромное спасибо man2002ua and DENNN

Если очень очется то придется

первая запись в файле будет означать кол-во структур с именами или (что гораздо лучше) длину этого каталога.

Нюансы только в случае изменения размеров данных. Пусть у тебя есть база файлов из двух записей по 10 Мб. Тебе надо изменить 1-ю запись и ее размер увеличился до 15 Мб - хорошо, дописали в конец как третью запись (первая при этом пустая с размером в 10 Мб!). Теперь надо добавить еще запись с размером 9 Мб - по этому алгоритму - снова в конец (хотя первый блок мог бы ее вместить без проблем). Ну и так далее.

Цитата(DENNN @ 21.4.2003, 10:43)

А насчет архиватора, то тут есть не сразу заметные недостатки. Такую систему, как пытаешся создать ты имеет смысл использовать когда у тебя множество больших и не очень файлов ( к примеру звуки и видео вставки к игре). Естественно общий объем таких файлов будет как минимум 150~300 МБ. Представь сколько пользователю придется смотреть на пустой экран прежде чем твое приложение все распакует и запустится. Это понятно. Но есть еще другие нюансы, такие как: если на жестком диске, куда будут распаковываться файлы не хватит свободного места, программа просто не запустится, высокая дефрагментация диска при каждом запуске проги, куда распаковывать файлы? в свою папку или каталог TEMP виндов?

Экран при желании можно сделать и не пустым...
это не DOS когда на время запуска другой программы своя почти труп
Насчет если не хватит места...
в программе проверку на наличие доступного места прийдется делать в любом случае и при использовании архиватора и если не использовать то тоже...
куда распаковывать!!!! )))
да туда где должны оказаться файлы, в каталог игры...
вы что не в курсе что если знать ключи архиватора как следует то можно сделать так что архиватор при распаковке полностью воставновит структуру папок заархивированного каталога?
Таким образом как раз можно лишиться части проблем по организации размещения файлов...
но тут правда одно но... я не подумал что возможно разобраться с ключами архиватора будет не намного проще чем разобраться с файловыми функциями
я подобную фишку проворачивал когда мне нужно было в БД организовать резервное сохранение базы раз в неделю...
что бы избежать дальнейших споров... я не говорю что способ с архиватором лучше, он просто проще ...

Про ключи, и что вин многозадачная ос всем я думаю известно. А вот недостатки я расписал далеко не все, не считая самого вопроса: зачесм для "статической" проги держать файлы в архиве, если все равно их каждый раз придется распаковывать? Запуск проги еще только половина вопроса. Что будет, если ты запустил экземпляр из локальной папки, а через некоторое время в сетки запустили прогу с твоего локального диска. Каталог программы физически будет тот же самый, значит при запуске она заново распакует файлы поверх тех, с которыми ты работаешь и возможно уже изменил.
Скажешь: "хорошо, будет создавать временную папку с уникальным именем и распаковывать туда"? Cмотри дальше. Удаленно запущенный экземпляр завершает свою работу и, естественно, архивирует файлы, удаляя исходники. Значит либо локальный экземпляр вдруг останется без своих файлов, либо удаленный экземпляр не сможет их удалить и локальный затрет все изменения.
Я же говорю, если подумать внимательно, то скрытых нюансов очень много и простая программа раздуется в 2-3 раза.

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