Файл произвольного размера

зойчем? для считывания данных в неограниченных объемах есть /dev/zero

> в хр и следующих есть fsutil или как то так, которая создает его мгновенно в отличие от dd

Ну-ну. Файлы с дырами и Linux быстро создает.

спасибо, проглядел опцию.

off_t anysize = (размер);
char c = 0;
int fd = open("myfile", O_CREAT|O_RDWR);
lseek(fd, anysize-1, SEEK_SET);
write(fd, &c, 1);
close(fd);

Вот вам «моментальное» создание файла произвольного размера, только если размер будет очень большим (гигабайт, терабайт...), то время создания такого файла увеличится, т.к. нужно будет заполнить таблицы адресов будущих блоков. Да, на диске такой файл будет занимать только 1 байт + место для адресных блоков.

(Добавлю, что если вы хотите получить файл > 2Гб, нужно либо пользоваться 64-битной системой, либо явно указать, что у вас 64-битный off_t).

Только надо сказать, что файл состоит в основном из дыры :)

>зойчем? для считывания данных в неограниченных объемах есть /dev/zero

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

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

Тогда как минимум /dev/urandom, иначе рар поужимат нолики-то :)

Тогда как минимум /dev/urandom, иначе рар поужимат нолики-то :)

Неправильно как-то мыслите: в «архив с варезом» надо выкладывать недавно мелькавший на ЛОРе архив с простенькими вирусами + sms-блокировщик :)

>Неправильно как-то мыслите: в «архив с варезом» надо выкладывать недавно мелькавший на ЛОРе архив с простенькими вирусами + sms-блокировщик :)

Точно! Спасибо за идею. Запомню на будущее :)

> т.к. нужно будет заполнить таблицы адресов будущих блоков.

хм. откуда тогда избыточная фрагментация берётся при таком методе? (один lseek в конец, а затем запись в произвольные места файла, как в торрент-клиентах)

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

И как же это объясняет «т.к. нужно будет заполнить таблицы адресов будущих блоков.» ? По-моему как раз опровергает :)

Если фс поддерживает sparse-файлы, то ничего не будет заполнено. У себя в таблице она отметит «по смещению XXX в иноде YYY оставить sparse-область размером ZZZ», и никаких выделений блоков/экстентов.

Выделение блоков или экстентов пойдет уже при записи реальных данных в эту самую sparse-область.

И как же это объясняет «т.к. нужно будет заполнить таблицы адресов будущих блоков.» ?

Если у вас файл имеет размер, скажем, 1Тб, то стандартной таблицы адресов блоков не хватает, и создаются дополнительные таблицы. Не верите - попробуйте сделать lseek на 1Тб и записать 1байт в такой файл. Увидите, что занимать на диске он будет не 1 и даже не 512 байт, а несколько мегабайт.