Amit én írtam az nem ürít sehonnan semmit. A chkdsk parancs csak a lemez integritását és az állományok sértetlenségét vizsgálja. Az algoritmus kicsit komplikált, de a lényege ez. Tehát, ha a chksdk után felszabadul hely, akkor nem valószínű az, hogy ezt valós állományok törlésével éri el. Inkább arról lehet szó, hogy az MFT-ben (ez afféle katalógusként fogható fel az állományokról, azok elhelyezkedéséről, méretükről stb.) hibás bejegyzések képződnek 1-1 állomány méretére vonatkozóan.
Hogy mitől lehet ez? Hát a búbánat sem tudja megmondani látatlanban. Hosszas kurkászást igényel. Jellemzően temp mappákban 0 byte méretű állományok szoktak árulkodó jelek lenni. (látszólag nem foglalnak helyet de valójában igen.) De ez nem biztos, máshol is lehetnek.
Ez rendellenes dolog? Egy SSD-nél egyáltalán nem biztos, hiszen a háttérben működő TRIM felelős azért, hogy a cellákat felszabadítsa törlésnél, de ezt csak akkor teszi meg ha szükséges, mert már nincs szabad hely. Különben nem. (miafenének írná ki nullásra azt a területet, amíg nem muszáj)
Viszont ezt el kéne előled rejtenie, szabadnak kellene mutatnia a helyet. Hogy ezt miért nem teszi passz.
A második lehetőség az, hogy olyan program fut a háttérben, ami megnyit és készít ideiglenes állományokat, de amikor a gépet kikapcsolod ez a program nem zárja le a munkáját normálisan és úgymond "félkész" lezáratlan állományokat hagy ott. (ezek az említett 0 byte-os állományok) Sajnos erre a hibára igen komoly szoftverek is hajlamosak. Legutóbbi ilyen esetem egy win2012szerveren futó firebird adatbázismotor kapcsán volt. Ez a windows/temp mappában hagyott 0 byte-os nak mutatott, de valójában !többtíz! gigabyte helyet foglaló szemetet.
Összefoglalva: Ha a gép nem kritikus dolgot csinál csak otthoni használatos és az ssdlife jónak mutatja az ssd-t én annyira nem aggódnék ezen, ha mindenképp hagy néhány giga szabad helyet. A további vizsgálódáshoz látni kéne a gépet és átbogarászni, mert így látatlanban passz.