Цитата

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. читал я о таком способе подсчета ошибок, где предлагается каждое неверное действие считать за ошибку, а каждое лишнее действие за половину ошибки.