Re: checkdisk i defragmentacja wybranego folderu lub pliku

Autor: Lawrens Hammond <valhalla_at_interia.pl>
Data: Wed 31 Jan 2007 - 14:04:52 MET
Content-Type: text/plain; charset="iso-8859-2"
Message-ID: <45c094bf$1@news.home.net.pl>

Użytkownik "Wiktor S." <ANTISPAM@wswiktor.AT.poczta.DOT.fm> napisał w
wiadomości news:epiou0$43p$1@news.onet.pl...
> > Powiedziałbym więcej - może to się okazać niebezpieczne, gdy np.
> > nastąpi splątanie się plików (crosslinked) z 2 różnych katalogów, a
> > skoryguje sie wpis tylko dla jednego z plików, to można bezpowrotnie
> > uszkodzić drugi plik.
>
> crosslink oznacza, że już doszło do bezpowrotnego uszkodzenia co najmniej
> jednego z dwóch plików.

Niekoniecznie.
Wystarczy po prostu, że ostatni blok dla pliku nie jest zakończony
znacznikiem EOF, tylko ma podlinkowanie do jakiegoś innego ciągu. Załóżmy,
że w połowie np. pliku Kernela. Tym samym żaden z tych plików nie jest
uszkodzony, a jedynie zaszwankowało linkowanie, zaś po prawdzie pliki nie
będą mieć części wspólnej danych. A często w najgorszym razie do "zwalonego
bardziej" doklei sie troche śmieci, które wystarczy obciąć. Wyobraź sobie
teraz program naprawiający, który obetnie owo dowiązanie z dalszym
łańcuchem, pozbawiając Kernela połowy jaja, bo ubzdura sobie, że wyzerować
należy cały łańcuch alokacji. Nie muszę chyba pisać, czym to się skończy dla
systemu. Dlatego albo naprawic skrzyżowanie dla obu plików, albo go nie
ruszać i nie pozwolić na tych plikach nic zapisać. Naprawa dla jednego (bo
tylko ten jeden jest w żądanym katalogu) albo obetnie łańcuch, albo go
uszkodzi, albo nie da rezultatu, zależy od układu.
Prawidłowo, system powinien najpierw skopiować oba pliki na bok, skasować
obecne wpisy (lub po naprawie poprawnie je podlinkować) i łańcuchy alokacji,
oraz przywrócić pliki tam, gdzie powinny leżeć.
To nie jest wydumana sytuacja. Ino tylko skutki były mniej poważne, bo
obcięło nie plik jajca, ale jakiś mało ważny *.INI, OIDP, łatwy do
odtworzenia.

>
> > Naprawa systemu plików IMHO musi być
> > kompleksowa, albo żadna. To nie są lost clusters, które w zasadzie
> > poza zajmowaniem niepotrzebnie miejsca większej szkody nie czynią.
> > BTW. Spotkałem się z sytuacją, gdy crosslinked dla plików na
> > dyskietce był zrobiony celowo.
>
> A to ciekawe... crosslink nie, ale w ramach zajęć celowo robiliśmy

Nie w PC, ale na dyskietce do Commodore64, gdzie tylko poczatki plików były
różne, a ich końcówki takie same. Ponieważ wszystkie pliki w normalny sposób
nie mieściły się, postanowiono, że owe wspólne końcówki (po kilka(naście?
nie pamiętam dokładnie, bloków) zostaną zapisane w jednym łańcuchu, a
poszczególne wersje zostaną do niego podlinkowane. Oszczędzono dzięki temu
sporo miejsca.

> badsectory :-)

Uszkadzając nośnik (na Commodore64 i jego stacji 1541, będącej autonomicznym
komputerem, można było manipulując buforem zapisu spreparować konkretnie
uszkodzony sektor, do odzyskania oczywiście przy formatowaniu), czy
wstawiając znacznik BADa? Bo jak to drugie - to tak "uzdatniałem" dysk
(pecetowy), którego żadne formatowanie nie brało, bądź wieszał się przy
zapisie permanentnie zwracając komunikat np. "Błąd zapisu podczas odczytu na
dysku..." (!) i tylko power-off reset przywracało dysk do działania.
Wystarczyło ręcznie edytorem dysku zafiksować uszkodzone (scandisk, NDD,
systemowy nie brały tego) bloki, aby z dysku jakiś czas jeszcze dało się
korzystać. Oczywiście, nie do przechowywania ważnych danych :)
BTW - mistrzem nie jestem, ale życie zmusiło mnie do opanowania komodzianego
systemu plików na tyle, żeby umieć samemu napisać program do odzyskiwania
skasowanych plików :) W końcu udało mi się dowiedzieć co i jak - i parę
ciekawych pomysłów wcieliłem w życie :) Aale to już nie WinNT, zatem kończę
:)) No, może uda mi się NTFS rozszyfrować na tyle, że sobie z nim ręcznie
poradzę :)) Bo FATy w miarę kumam :)

-- 
LH
http://www.youtube.com/watch?v=xmsV9R8FsDA
http://www.youtube.com/watch?v=PJt3r9jv9r8
Received on Wed Jan 31 14:10:09 2007

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Wed 31 Jan 2007 - 14:42:05 MET