Чудеса виндоуз...

[psilogic]

Можно создать на виндах (XP, NTFS) большой файл на 5 Гигов, заполненный нулями, и притом быстро?

Если заполнять все 5 Гб выровненными блоками по 4 Кб, то у меня это занимает где-то 100 секунд. Плохо. Изменение размера блока не влияет. Функция chsize работает примерно столько же, но нет возможности показать пользователю "прогресс".

Но есть забавный способ. Надо открыть файл, сделать "fseek" на 5 Гб вперед, записать туда один нулевой байт (fwrite) и сказать fclose. Через секунду файл на 5 Гб готов.

Но рано радоваццо. Стоит попытаться записать в конец этого файла один-единственный ненулевой байт, сказать flush и... все виснет на те же 2 минуты без всяких шансов на показ "прогресса". Чудес не бывает, увы :(

Comments

[fregimus.livejournal.com]

Посмотрите NTFS sparse files (http://www.flexhex.com/docs/articles/sparse-files.phtml). Кажется, это то, что Вам надо.

[psilogic.livejournal.com]

да мине уже ниче не надо... :)

[wizzard]

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

[psilogic.livejournal.com]

Меня, скорее, заботит не то, как позабивать, как то, чтобы потом не висло при записи 1 байта.

[morfizm.livejournal.com]

Будьте осторожны, на Win98 & Win95 fseek на конец + записать нулевой байт создаст не файл, заполненный нулями, а файл, заполненный junk'ом, который был на винче в этот момент.

[psilogic.livejournal.com]

Да, я и не рискую, честно заполняю файл, а то мало ли, что за диск. В FAT-е так и получается, как вы говорите. А в NTFS-е, похоже, некая оптимизация (там ссылку выше давали), но оптимизация какая-то глюкавая.

[fregimus.livejournal.com]

Ссылку выше не на оптимизацию давали, а на особую разновидность файлов. Если их прямыми руками делать (http://msdn.microsoft.com/en-us/library/aa365566(VS.85).aspx), никаких глюков не происходит; боюсь, здесь наш замечательный хозяин немного заблуждается.

[psilogic.livejournal.com]

Но интересно, тот эффект, что я описал, откуда он происходит?

[fregimus.livejournal.com]

Не знаю. Надо думать, так файловая система устроена, подсказывает мне капитан О.

[psilogic.livejournal.com]

я предположил, что системные функции seek+write в такой ситуации вставляют sparce-блок, но, видимо, как-то глюкаво...

для моей задачки sparce-файлы не подходят, к шыжалению

[fregimus.livejournal.com]

В документации написано, чтобы на это не рассчитывали. А так это или нет — не написано. Можно проверить (http://msdn.microsoft.com/en-us/library/aa364582(VS.85).aspx), если интересно — но что с этим знанием потом делать?

[fregimus.livejournal.com]

SetFilePointerEx (http://msdn.microsoft.com/en-us/library/aa365542(VS.85).aspx)

Note that it is not an error to set the file pointer to a position beyond the end of the file. The size of the file does not increase until you call the SetEndOfFile, WriteFile, or WriteFileEx function. A write operation increases the size of the file to the file pointer position plus the size of the buffer written, leaving the intervening bytes uninitialized.

Выделение мое. Рассчитывать на то, что после такой процедуры, какую Вы описали, на то, что файл окажется заполненным нулями, нельзя. С другой стороны, в NTFS иначе было бы невозможно: данные стертого файла никогда не делаются случайно доступными, таков был один из принципов защиты данных при разработке этой файловой системы. Но пользоваться этим знанием все равно некошерно. Вместо нулей там может оказаться какой-то другой стирающий шаблон, например. Микрософт завещал нам считать эти данные неинициализированными, о чем kuzmen нас совершенно справедливо предупреждает.

[lomka.livejournal.com]

Доживём до 5-гигабайтных регистров - и будет Вам чудо ).