I czasem sie robi. Ale NT (czyli XP też) jest cwany i bywa, że nawet to nie spowoduje sprawdzenia dysku, nawet ręczne popchnięcie wiele nie da.
Tylko teraz, jaki to miało bufor, coby profilaktycznie dopchnąć tyle (później się obetnie) tyle, aby wszystko, co nas interesuje, znalazło się w pliku. Już w C64 ten problem występował, tyle, że wiadomo było, ile dać nadmiaru, żeby było z czego obcinać. No i ręczne zamknięcie pliku bardziej skomplikowane, bo całkowicie ręcznie, bądź odpowiednim programem (ja zwykle ręcznie załatwiałem, wspomagając się jedynie programikiem, który sczytywał mi odpowiedni sektor, a to tylko po to, żeby w ogóle wiedzieć, gdzie jest wpis, który trzeba zmodyfikować, potem przestawienie bitu 7 (jego znaczenie
0 - plik otwarty, 1 - zamknięty) w znaczniku rodzaju pliku i już, na koniec "validate" dla odświeżenia BAM. NTFS, jako system z atomowymi operacjami zapisu, średnio daje się sprowokować do zrobienia automatycznie chkdsk, zwykłym wyłączeniem zasilania. Ale jest prosty sposób, z wiersza poleceń/okna "DOS"owego zapodać: fsutil dirty set <volumin>gdzie <volumin>, to litera, albo ścieżka zamontowania zasobu. I wtedy pyk hebel... Przyznam, że muszę poćwiczyć, choć jak wtedy próbowałem, to chyba nawet nie bardzo trzeba, bo przy zapisie sekwencyjnym nie ma zadeklarowanej długości pliku i nie jest ona rezerwowana, jak w sytuacji, gdy wiadomo (no, system musi wiedzieć przecież, sama nasza wiedza nie styknie), że "zapisujemy
4294967295 bajtów danych". A to się wiąże z tym, że do pliku dane dopisuje się (nasz QBasic DOSowy) na bieżąco (i nawet nie wiem, czy to się w przerwach między porcjami samo nie jakby nie zamyka... (nie chodzi o BASICowe CLOSE, bo to się zrobić nie daje)) i tylko ten bufor, aby nadmiarem zepchnąć jego zawartość na nośnik. A dopilnować trzeba, bo czasem ten ostatni bajt najbardziej znaczy... taka przewrotność losu, jak np. archiwum rozpakować nie zechce...