Пичове, срещнах проблем който не ми е ясно как да реша, и питам тук.

Имаме проста ситуация. Трябва да се създаде един 500 мегабайтов файл (а в перспектива ще се качи до 4 гиги), без да се пишат данни вътре, максимално бързо. Обаче в момента когато го затварям системата заспива и диска светва червено толкова време, колкото и трябва за да запише същото количество данни (което ми е целта да избягна). Което за към 4 гиги файл на флешка е към четвърт час.

Примерът е пределно прост:

FILE* f = fopen (fname, "wb");
fseek (f, 500000000, 0);
fwrite (&f, 1, 1, f);
fclose (f);

и с Виндовски щуротии:

HANDLE h = CreateFile ("myfile",GENERIC_WRITE,0,NULL,CREATE_ALWAYS,0, NULL);
SetFilePointer(h,500000000,NULL,FILE_BEGIN);
SetEndOfFile (h);
CloseHandle (h);

Действието се развива под Windows XP SP3. Няма значение дали диска е под NTFS или FAT.

Подозрението е че OS-а се грижи да си запълни нещата с нули до края на файла, демек това е някаква фича на операционната система. Имате ли някакви идеи как това може да се изключи поне временно за да се реши проблемът

може би флашката така иска, иначе върху диск изглежда моментално сякаш се създава файла.




NE SUTOR ULTRA CREPIDAM

И върху диск е абсолютно същото. И аз първоначално се усъмних във флашката, ама не е.

Не мисля, че има начин с win32 api-то да стане. Windows трябва да се грижи данни от друг изтрит фаил да не попаднат в тялото на нов фаил, защото ще бъде сериозен секюрити проблем. Не мога да намеря сега точно къде в msdn-а го пише, но съм доста сигурен, че няма да стане така.

Но с директно манипулиране на файловата структура на ниско ниво е възможно да се направи голям фаил. Само, че трябва нещо на ниво диваиз драйвер и освен това по един начин ще стане при ntfs а по друг начин на флашката където е fat32.

верно това с изтрития файл е сериозен довод.
иначе не е необходимо на ниво драйвер да падаш за да ровиш на ниско ниво, отваря се файл с име \\.\X: и получаваш директен достъп до диска. не съм пробвал за флашка дали бачка, ще е интересно.




NE SUTOR ULTRA CREPIDAM

Странно, и двата снипета си бачкат просто пирфектну (vc/ntfs@xp и gcc@ubuntu), под милисекунда.

Тук виждам някакви идеи за подобен проблем:

Съдържаниет е скрито
Влезте за да го видите

Явно тая работа зависи от някакви допълнителни настройки в регистрито. И аз съм го правил навремето, пак под Виндовс, и помня че беше бързо, но на друга система.

Само като идея, да не пишеш в компресиран фолдер? Там на теория може да нагазиш в кофти ситуации.

Благодаря за вниманието. Аз преди да питам тука доста обходих нета, и попаднах на това. При мене обаче обръщението към DeviceIOControl с параметри от групата FSCTL_SET_ZERO_DATA и FSCTL_SET_SPARSE (което беше другата идея под NTFS) просто гърми и връща FALSE. Почвам да се питам дали и няма нещо на системата, под която се опитвам да го пусна... Щото всичко друго в нея си цъка. Ама тогава каква ми е гаранцията че на друга цъкаща система пак няма да се прояви, след като не е ясно какво е?

Примерът дето е даден в линка ти:

fsutil file createnew c:\$delthis.bin 1234567890

при мене пак се изпълнява много бавно, на диск който е под NTFS и уж поддържа sparse files (GetVolumeInformation() връща флаг, в който има такава информация). Има нещо забраняващо, ама не е ясно какво е...