Nem akarok nagyon belemenni, próbálom röviden (bocs a hosszúságért ). Többféleképpen lehet egy új, előre ismert méretű file-t véletlenszerű írásra előkészíteni. A teljesség igénye nélkül pár, amit Windows-on szoktak az ottani filerendszerrel:
1. NTFS-en (és egyébként exFAT-on is) lehet olyat, hogy lefoglaltatjuk a teljes fileméretet előre, nem sparse file-ként, ekkor létrejön egy nagy file, többnyire egybefüggő blokként a bitmap-ben (ha van ekkora egybefüggő szabad rész), ez egy pillanat műve. Ha ezt feltöltjük tényleges adatokkal, attól a már lefoglalt blokkok maradnak a helyükön a bitmap-ben(*).
2. Aztán lehet olyat, hogy ún. sparse file-ként jön létre, ekkor a hex 00-t tartalmazó részek nem foglalnak tényleges blokkot a bitmap-ben, csak metaadatként léteznek. A kezdeti létrehozása ennek is gyors.
3. Aztán van még az a módszer, hogy mindig akkorára növeli a file-t (ha még nem akkora), amilyen piece az elejétől számítva éppen megérkezett, az üres részeket pedig 00-val feltölti - ilyet gondolom semmilyen torrent kliens nem használ, mert ha előre ismert a teljes fileméret, van jobb módszer, így nagyon béna és lassú is (itt is több írás lesz, mint a torrent mérete, ha nem szekvenciálsan érkeznek a darabok és folyamatos file átméretezéssel jár) és közel annyira töredezett lesz, mint a 2-es módszerrel.
Ill. van a 4-es módszer, amikor simán 00-val feltöltve létrehoz egy file-t, mielőtt elkezd bele véletlenszerűen írni, de nem az 1-es trükkel; ezt legfeljebb olyan filerendszeren van értelme, ami sem az 1-es trükköt, sem a sparse file-t nem támogatja (pl. FAT16/32, de ezeket már nem sokan használják, főleg nem torrentre).
Ezek egyébként mind sima user jogosultsággal,+ OS API hívással megvalósíthatóak, bármilyen program megteheti.

A qBittorrent sajnos a 2-es megoldást használja, és erről nem tudom lebeszélni (pedig a libtorrent elvileg tudja) ezt kérdeztem; amivel HDD esetén az a baj, hogy amikor a 00-t "tartalmazó" (csak metaadatként létező) részekre írásra kerülne (nem 00) adat, akkor keres neki helyet a bitmap-ben, így általában a legelső akkora (az éppen írandó résznek megfelelő, ill. és/vagy az adott file-ra vonatkozó sparse beállításaiban megadott - de hagyjuk a részleteket) egybefüggő szabad helyet fogja megkapni, ettől pedig az ilyen file írása így szépen feltölti a töredezett szabad helyet a file darabjaival. Én az 1-es módszert szeretném (+ 00-val előre feltöltés, lásd a *-ozott részt), mert HDD-n nem érdekel, hogy 2x íródik ki a torrent adatmennyisége és ha van elég cache-e a torrent kliensnek, akkor a 00-val feltöltéssel végez is, mire az megtelne, így a letöltési sebesség sem esik le és így lesz a legkevésbé töredezett.
Közben olvasgattam és úgy látom, ez több éves probléma és az igazi gond a fejlesztők fejében van, így ebből a programból is magamnak kell fordítanom egyet. (Úgy tűnik, nem értik, hogy HDD-n nagyon nem jó torrent letöltéshez sparse file-t létrehozni, mert ha nem töküres a partíció, mindenképpen töredezett lesz, vagyis lassabb lesz a kezelése.)
A nevezett beállítás egyébként inkább arra vonatkozik, hogy ha több file-ból áll a torrent, akkor mindegyiket előre lefoglalja és nem csak akkor, amikor érkezik hozzá piece.

*: Véletlen írással (random helyekre, ahogyan egy torrentnél jönnek a piece-ek) ilyen file-ba sajnos viszonylag lassú (kb. a teljes sebesség negyede) írni, ezért fel szokták tölteni szekvenciálisan (az teljes sebességgel megy) 0-val, utána már a véletlen írás is gyors.

The only real valuable thing is intuition.