atra już sformatowałem, poprawiwszy uprzednio ręcznie pozycję DUP.SYS w katalogu - dlatego, że to, jak się okazało, była moja jedyna dobra kopia MyDOS-a 4.50, więc musiałem ją odzyskać :/

DOS.SYS się będzie bootował dobrze mimo przesortowania, bo w bootsektorach jest zapisany numer pierwszego sektora zajętego przez ten plik, a na to sortowanie katalogu nie wpływa. Jak DOS.SYS się zaczynał od sektora nr 4, albo 550, to po sorcie nadal się będzie zaczynał od 4 (albo 550). Kod bootsektora nie odczytuje katalogu, więc nie ma pojęcia, jaki "powinien" być numer pliku DOS.SYS. Nie zauważa zatem, że się on nie zgadza.

DUP.SYS natomiast - tak samo jak każdy zwykły plik - się nie odczyta, bo numer pozycji w katalogu przestanie się zgadzać z numerem zapisanym przy tworzeniu tego pliku.

Taka sytuacja:

Nr Nazwa
0  DOS.SYS
1  DUP.SYS

DUP.SYS jest drugi w katalogu więc ma nr 1 (licząc od zera). A więc, w każdym sektorze pliku DUP.SYS każde pierwsze 6 bitów linku sektorowego (bajt 125 sektora SD/ED albo 253 DD) będzie miało wartość $01, bo taki jest numer tego pliku (a numerem pliku jest pozycja jego wpisu w katalogu).

Teraz, załóżmy że katalog przesortujemy i po sortowaniu mamy taką sytuację:

Nr Nazwa
0  DUP.SYS
1  DOS.SYS

DOS.SYS się odczyta przy boocie, bo bootloader nie czyta katalogu, więc w nosie ma, czy pozycja w katalogu i numer pliku się zgadzają. Natomiast DOS.SYS po uruchomieniu próbuje otworzyć DUP.SYS jako normalny plik. Ten plik ma w katalogu nr 0 (bo jest na pierwszej pozycji) ale w sektorach danych (w pierwszych 6 bitach linku) ma zapisany nr 1. Więc następuje mismatch, błąd nr 164, plik nie daje się odczytać.

Przemieszczenie pliku w katalogu jak najbardziej "wpływa". Bo: nr_wpisu_w_katalogu = nr_pliku, a nr_pliku jest zapisany w sektorach danych pliku i musi się zgadzać z nr_wpisu_w_katalogu, bo inaczej DOS zgłasza błąd 164.