Как записать файл размером >4Gb в C++?

Question

[bluebyte]

В процессе решения одной учебной задачи столкнулся со следующей проблемой.

В существующий пустой файл можно добавить данные следующим образом:

ofstream ofs("file", ios_base::binary | ios_base::in | ios_base::ate);
long long pos = 5000000000;
ofs.seekp(pos, ios_base::beg);
ofs.write(as_bytes(pos), sizeof(pos));
ofs.close();

При этом файлы больше 4 Гб создаются таким образом без проблем. Но как только размер файла пересекает «заветную» цифру, добавлять данные таким образом не получается.

Вопроса три:
1. В чем не прав?
2. Как исправить?
3. Что обычно используют для работы с большими файлами?

В дополнение:
— NTFS
— VC2010 32b
— Windows 7 x64

Answer 1

[Next_Alex]

Что-то мне подсказывает что проблема в том что размер типа int, который используется в ofstream::seekp и в ofstream::write равен 4 байта. А это значит что с помощью этих методов принципиально нельзя записать больше 4 Гб.
Здесь есть ответ:
stackoverflow.com/questions/293672/reading-files-larger-than-4gb-using-c-stl

Answer 2

[ixSci]

1. Если у Вас используется ofstream, то флаг должен быть ios_base::out, а не ios_base::in
2. Честно говоря, я не знаю, можно ли расширять файл способом, который Вы используете. Я не нашел ни опровержений ни доказательств этому. Но если учесть, что seekp устанавливает указатель внутри последовательности, я бы не стал надеяться на гарантированное поведение в подобном случае.
3. VS 2010 STL работает с файлами размером 2^64, так что в этом затыка нет.

Comments

[ixSci]

Нашел. Нельзя так делать. C++11 finla draft 27.9.1.1/17

If sp is an invalid stream position, or if the function positions neither sequence, the positioning opera-
tion fails. If sp has not been obtained by a previous successful call to one of the positioning functions
(seekoff or seekpos) on the same file the effects are undefined.

[ixSci]

Что обычно используют для работы с большими файлами?

Смотря что требуется, если требуется наивысшая производительность то выгоднее всего использовать OS API. Это даст большую свободу(работу минуя буферы и т.д)

[ixSci]

И последнее: Вы открываете файл с флагом ios_base::ate, что равносильно открытию без него и немедленному вызову ofs.seekp(pos, ios_base::end);. Зачем Вы потом вызываете ofs.seekp(pos, ios_base::beg);
мне не понятно. Если Вам просто нужно добавить чтото в конец файла то откройте файл следующим образом: ofstream ofs(«file», ios_base::binary | ios_base::out | ios_base::app); и пишите в него. При этом то, что Вы записали будет добавлено в конец

[Next_Alex]

а уже потом будете искать как считать то что было туда записано

[bluebyte]

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

2. Спасибо.

[ixSci]

Если вы помните, то по умолчанию поток открывается в режиме trancate

Не помню, потому, что это не так. explicit basic_ofstream(const string& s, ios_base::openmode mode = ios_base::out); Моежет видеть, что ios_base::trunc не является дефолтным параметром.

Еще раз, если Вы открываете файл для записи, то зачем передавать ему флаг, который предназначается для чтения. Если Вам нужна и запись и чтение, то необходимо использовать объект класса basic_fstream или его алиас std::fstream и уже точно не std::ofstream с флагом ios_base::in. Вы делаете, что-то неверно. Возможно, Вы просто не понимаете механизма, как это работает. Можете написать пример, того что Вам нужно я его поправлю, чтобы это было работоспособным. Код в Вашем посте не верен.

[Next_Alex]

Код в Вашем посте не верен

Не цепляйтесь к несущественным деталям.
Лучше объясните каким образом потом считать данные, расположенные в зоне >4Гб, после того как записали их в файл в режиме append. Думайте на шаг вперед, а с флагами он сам разберется если это не банальная опечатка.
А ошибка в коде на самом деле есть и она гораздо серьезнее:

Зачем Вы потом вызываете ofs.seekp(pos, ios_base::beg); мне не понятно.

Мне вот понятно. Это сделано для того чтобы сразу увеличить размер потока до значения «long long pos = 5000000000;».
Но проблема в том, bluebyte, что, насколько я знаю, в стандарте ничего не сказано о поведении системы этом случае. А значит в зависимости от компилятора ( или даже его версии ), ОС и еще какой-то матери оно может изменяться и вместо увеличения размера потока Вы получите ошибку.
Кстати, ixSci, к сожалению проверить не могу, но возможно что просто этот хак заработал только с такой комбинацией флагов :)

[bluebyte]

Код, приведенный мной здесь — упрощенный, чтобы меньше было читать. Но он работает очень даже правильно, если речь идет о файлах размером до 4Гб. Вопрос по этому поводу я задавал здесь. На что получил ответ, который помог мне решить проблему.

Спасибо за обсуждение. Я уже решил использовать FileWrite/FileRead для решения своей задачи.

[Next_Alex]

Это правильно решение. Теперь главное больше не использовать таких хитрых хаков :)

[ixSci]

Лучше объясните каким образом потом считать данные, расположенные в зоне >4Гб, после того как записали их в файл в режиме append

А в чем проблема? ifstream+seekg(pos_more_than_4Gb)+read.

[Next_Alex]

Я конечно не претендую на звание гуру, но по-моему с помощью метода, принимающего в качестве аргумента 32-битное число, сложно переместить указатель чтения на позицию более чем 4294967295.

[ixSci]

MSDN врет.
#include #include int main()
{
std::cout << std::hex << std::numeric_limits<std::streamoff>::max() << "\n";
std::cout << std::hex << std::numeric_limits::max() << "\n";
std::cout << std::hex << std::numeric_limits::max() << std::endl;
return 0;
}
Вывод:
7fffffffffffffff
7fffffff
7fffffff
Флаги компиляции: /ZI /nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Debug\Test.pch" /Fa"Debug\" /Fo"Debug\" /Fd"Debug\vc100.pdb" /Gd /analyze- /errorReport:queue

[ixSci]

Гребаный хабропарсер:
#include \<iostream\>
#include \<limits\>

int main()
{
std::cout << std::hex << std::numeric_limits\<std::streamoff\>::max() << "\n";
std::cout << std::hex << std::numeric_limits\<long\>::max() << "\n";
std::cout << std::hex << std::numeric_limits\<int\>::max() << std::endl;
return 0;
}

[ixSci]

typedef _Longlong streamoff;
typedef _Longlong streamsize;

[Next_Alex]

в общем продолжение внизу :)

Answer 3

[Next_Alex]

В таком случае врет не только MSDN.
Кстати еще неизвестно как это значение обрабатывает сам seekg :)
В общем, я все равно не вижу смысла пользоваться стандартными потоками ввода-вывода — с ними только вечные пляски с бубном, плюс в режиме append не запишешь данные в произвольную позицию :)

Comments

[Next_Alex]

промахнулся, блин

[ixSci]

В потоках нет никакой пляски с бубном, все документированно и прозрачно. Если автор, по наущению некого «знатока» С++ написал код, который благодаря UB давал ему ожидаемый результат не значит, что нужны танцы. Нужно просто писать так, как это предполагает интерфейс.
Открывать с append вовсе не обязательно, я лишь предложил этот метод, так как решил, что автору необходимо писать в конец файла. А автору, реально, нужно было просто использовать std::fstream с дефолтными флагами и у него бы не было проблем в VS2010, по крайней мере.