Wygląda to na jakieś przekłamania systemu plików. Jeźeli chcesz, moźesz sprawdzić jakimś edytorem heksagonalnym (np. WinHex) szesnastkowe zapisy w pliku, porównując (piszesz, źe posiadasz kopie) z odpowiadającym plikiem prawidłowym. Jeźeli zawartość nie będzie się róźniła, lub róźnice będą nieznaczne, oznaczać to będzie, źe zawartość jako taka chyba uszkodzona nie została, ale system jakimś dziwnym sposobem interpretuje plik jako zbiór o zerowym rozmiarze (?).

UpDate 1
Krótka wycieczka po sieci, dzięki pomocom braci z ekipy google.com :wink: zdaje się potwierdzać wersję sugerującą uszkodzenie systemu plików lub przekłamanie zapisu bitowego samych plików. Według tego :arrow: źródła, prawidłowe oznaczenie daty w systemach DOSopochodnych (a jak widać, w XP sytuacja taka występuje takźe) musi zawierać się w przedziale 31.12.2107>. Pamięć komputera nie jest nieograniczona; nieograniczone nie mogą takźe być wartości, które za przechowywanie informacji o dacie i godzinie odpowiadają – ich rozmiar bajtowy jest ściśle określony i determinuje nam maksymalny zakres wartości, jakie dana zmienna moźe przyjmować (sytuacja ta jest nieco podobna do tzw. problemu roku 2000). Datę zatem obliczamy według wzoru:
y = f(C) = 1980 + C
Przez C oznaczyłem wartość, która tak naprawdę nas interesuje. Jak widać jest to róźnica między obecną datą, a liczbą 1980, czyli lewą granicą podanego przedziału. Jak moźna łatwo obliczyć, maksymalna wartość C to 127. To tylko o 1 mniej od liczby 128, która jest 7–mą potęgą liczby 2. Jednak liczba 0 (a taką wartość takźe C moźe przyjmować! – dla f(C) = 1980) z punktu widzenia informatyka to takźe równoprawna wartość, która ma swoje odzwierciedlenie w zapisie bitowym (oczywiście to 0000 0000). Łącznie mamy 128 moźliwych kombinacji, co odpowiada w istocie łańcuchowi 7 bitów. I właśnie w tych 7 bitach informacja o wartości C jest przechowywana. Analogicznie postąpić moźna w przypadku godzin, minut, sekund, dnia i miesiąca, z tym tylko, źe tutaj przechowuje się konkretne wartości, nie róźnice.
Godzina utworzenia sprawiających kłopoty plików to (wg systemu operacyjnego) 31 grudnia 2107 roku. Zauwaź, źe taką wartość otrzymamy, gdy ciąg 7 bitów decydujących o dacie tworzyć będą same jedynki (1111111_2 = 127_10). Ponadto, jeźeli łańcuch 5 bitów odpowiedzialnych za przechowywanie informacji o dniu zapełnimy jedynkami, otrzymamy wartość 11111, co odpowiada dziesiętnej liczbie 31. Sytuacja wygląda tylko nieco inaczej w przypadku miesięcy – tych moźe być maksymalnie 12, ale wartości odpowiedzialne za nie przechowywane są w 4 bitach (przy 3 otrzymalibyśmy zbyt małą ilość kombinacji). Co prawda wartość 1111_2 to 16_10, ale system nie moźe przecieź uznać 16–ego miesiąca, gdyź taki nie istnieje; najwyraźniej przyjmuje tutaj maksymalną wartość z zakresu, czyli 12 (1100 w zapisie binarnym). Podobne rozumowanie zapewne moźnaby przeprowadzić równieź w przypadku reszty zapisu daty.

Bardzo Cię przepraszam za te obszerne, teoretyczne dywagacje, ale tylko w ten sposób mogłem spróbować udowodnić moją tezę o naruszonym zapisie bitowym pliku. Z drugiej jednak strony, jeźeli informacje o dacie i godzinie zostały naprawdę nadpisane samymi jedynkami, nie tłumaczy to chyba zerowego rozmiaru całego zbioru. Chociaź... tutaj chyba wszystko jest moźliwe :wink:.

Dzieki za rade ale chkdsk nie wykazal zadnych bledow.
Moim zdaniem moga byc dwie mozliwosci :
wirus lub cos z dyskiem.
Ale jak widac ani antywirusy nic nie znalazly ani chkdisc wiec co?
Ma ktos jakis pomysl?
Dzieki z gory