asmdzen, я знаю винапи, но совершенно не знаю плюсов 
но вот какая-то open из io.h вроде возвращает хендл

нашел кое что интересное - boost::filesystem::resize_file(const path& p, uintmax_t new_size);
работает как truncate

оО..

буду знать 

вот только и она и file_size требуют не хэндл а имя файла, получается что если файл уже открыт (ofstream и open) то выдает ошибку типа:

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

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

Добавлено через 4 минуты и 19 секунд
хотя сообщение в ислючении говорит что операция завершилась успехом  
оберни этот вызов в try-catch, и посмотри, файл изменяет свой размер?
но в любом случае изменять размер файла который уже используется, как-то не правильно. его размер может изменять использующий его код.

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


есть версия resize_file которая получает в качестве параметра ссылку на boost::system::error_code
и возвращает в нем код ошибки, но размер файла не меняется все равно.

осталось найти как увеличить выходной буфер записи данных в файл )

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


откуда мнение что он чем-то должен заполняться?


fstream.rdbuf()->pubsetbuf(ptr, size);

разве можно создать файл сразу с определенным размером??   


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

большое спасибо. т.е. я создаю этот буфер (насколько понял можно и перед открытием файла)? при уничтожении fstream'а он освободится?

Это сообщение отредактировал(а) asmdzen - 29.7.2011, 20:29

нет. создаешь файл. изменяешь его размер. и пишешь в него!  


пруф, пожалуйста.


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

файл и в самом деле был заполнен нолями )
всем спасибо, вопрос считаю закрытым.

кросплатформенный вариант:


Добавлено @ 21:32
у меня немного иначе написано.


в общем, могу смело утверждать одно: никакое расширенное пространство нулями не заполняется. ибо сейчас я расширил файл до 100Гб, и операция завершилась мгновенно.
предполагаю, что при чтении из расширенного пространства ты читаешь нули потому, что ОС реально с диска ничего не читает, ибо знает, что эта область зарезервирована и в нее ничего никогда не писалось.


Это сообщение отредактировал(а) boostcoder - 29.7.2011, 21:35

так и есть. прочитал расширенных 100Гб, и никакой активности на HDD не возникло 

видимо так и есть, я просто предпологал что туда что-то пишется из-за этого 
т.е. я думал что это похоже на операцию malloc, а в линуксе еще выполняется ZeroMemory )



не могу понять как это возможно

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


Это сообщение отредактировал(а) asmdzen - 29.7.2011, 22:19

написал же выше:


Добавлено через 1 минуту и 22 секунды
по идее блоки которые добавились, имеют какой-то атрибут, который ядро проверяет при чтении. смысл читать то, куда никто и никогда не писал?  все логично.

Это фича файловой системы. Называется sparse file.

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