Testoval jsem soubory:
         test16.c az test22.c

Pokusi se popsat obsah kazdeho z nich a doplnit me postrehy, takze:

Vytvoril jsem program di.exe, ktery slouzi ke snadnejsi orientaci na diskete, abych nemusel po kazdem testu odskakovat do linuxu a overovat spravnost provedeni programu. Di.exe cte root floppy disku a vypisuje na obrazovku jeho obsah jako
            cislo inodu : nazev souboru.
Jde o upravenou verzi funkce 'dir' z test20.c, nevypisuje pouze regularni soubory, ale vsechny, tedy i '.' '..', ale i soubory oznacene jako odstranene, tedy ty ,ktere maji idode 0.
Zdrojovy kod zde ./di.c . Vzhledem k tomu, ze jde o vysekany kus podprogramu z 'test20.c' , musi se pri linkovani
a kompilaci nastavit TESTPHASE 20 a zaroven spravny nazev souboru.

Musel jsem pozmenit strukturu 'message m' z modulu "lib\dir\dir.c", na 'static message m' u kazde pouzite funkce, jinak se s tim nedalo hybat a zaroven prepsat nazev fce 'sync()' na __Xsync(), kvuli dvojnasobne deklaraci v jednom z modulu.

Dale jsem narazil na dost zakerny problem nekde ve funkci 'creat' a na ni navazujicich funkcich, ktery se projevuje nasledovne.
Pri vytvareni novych souboru na diskete libovolnym testovacim programen pouzivajici funkci 'creat' hlasi spravne provedeni operace vytvoreni souboru. Jenze, kdyz jsem v linuxu soubor smazal, oznacil se jeho inod jako 0 a soubor na diskete pochopitelne zustal, ale oznaceny jako smazany. Kdyz jsem ted ale spusti stejny testovaci program, ktery mel tento soubor
vytvorit znovu, program skoncil bez zjevne chyby, kterou by hlasil ven, ale dotycny soubor, drive smazany, na diskete nevytvoril. Jedine reseni bylo preformatovat disketu, nebo ve zdrojovem kodu zmenit nazev vytvareneho souboru a provest znovu kompilaci a nasledne spusteni programu.
Tento problem se vyskytuje ve vsech testech pouzivajici 'creat':
            test17 test18 test19 test20 test21 i test22.
Pri popisu jednotlivych testu se tedy tomuto problemu vyhnu.

Takze:

Test16
       Jednoduch test cteni souboru 'file.1st', doplnil jsem odkazy do 'dir.c' stejne i do ostatnich testu.
       -bez problemu
        test16.c 

Test17
       Test vytvoreni noveho souboru 'file.17', prekopirovani souboru 'file.1st' do tohoto souboru, zavreni a znovu otevreni pro cteni souboru 'file.17', provedena kontrola spravnosti kopirovani.
       -bez problemu
         test17.c

Test18
       Zapis dlouheho souboru 'file.18', omezil jsem na 16kB. Musel jsem zkratit nazev file.seek na file.18, protoze nechtel se ctyrznakovou priponou pracovat, akceptoval jen tri znaky v pripone, jinak soubor nevytvoril.Dale mel lseek nastavit
ukazatel do souboru na pocatek, coz se mi povedlo teprve po zavreni prave naplneneho souboru a znovu otevreni pro cteni!
Jestli ze jsem soubor nezavrel vratil mi lseek hodnotu1, jinak po zavreni souboru pote co jsem do nej zapsal a nasledovnem
jeho otevreni pro cteni probehl lseek spravne a vratil predpokladany vysledek, coz je pozice po nastaveni ukazovatka do
daneho souboru..
Jiste reseni muze vyplyvat z nasledujiciho testu 'test19.c'.
         test18.c

Test19
       Na rozdil od predchoziho testu se mi podarilo hned po vytvoreni prazdneho souboru lseek nastavit na pozadovanou pozici, a to 1024 B a za ni doplnit pozadovanych 1024B znaku.

Jedine reseni, co me napada je, zda neni lseek v predchozim pripade ovlivnen zapisem do souboru a nasledovnym nastavenim
pozice lseek. Vypada to ze lseek funguje spatne prave bezprostredne po zapisu dat do souboru, kdezto lseek pri provedeni
v novem, prazdnem souboru probehne v pohode.
        test19.c

Test20
       Vytvoreni souboru 'file.20' probehne bez komplikaci, nasledny prikaz 'dir' vypise spravny obsah fdd, 'link' vytvori soubor file.lnk, 'dir' znovu vypise obsah fdd uz i s 'file.lnk', kde inode 'file.20' a 'file.lnk' je stejny , potom by mel 'unlink' zrusit link,
ktery se po dalsim 'dir' opravdu ztrati, zustane pouze 'file.20'. Jestlize ale spustim program 'di.exe' po skonceni testu 'test20.c', zjistim, ze linkovy soubor 'file.lnk' stale existuje. Pri kontrole z linuxu jsem zjistil, ze oba dva soubory 'file.20' i 'file.lnk' maji stejnou delku. Nevim co si mam myslet o unlinku, protoze funkce 'dir' provedena bezprostredne po 'unlink' vypsala obsah fdd podle ocekavani bez linkoveho souboru 'file.lnk'.
Po skonceni programu vsak 'di.exe' linkovy soubor nasel jako regularni linkovy soubor odkazujici na 'file.20'. Reseni, zda byly spravne vyprazneny cache predtim, nez byl beh testovaciho programu ukoncen.

Mala poznamka, ve funkci 'dir' je provedeno 'open /' pro zjisteni obsahu rootu, ale po precteni vsech polozek neni soubor uzavren! Moznost chyby?
          test20.c 

Test21
       Vytvoreni adresarove struktury probehlo bez problemu.
         test21.c

Test22
       Zmena rootu take bez problemu.
         test22.c

To je zatim vsechno, bubu pokracovat a byl bych rad, kdyby se nekdo ozval s nejakym vyresenym problemem, ktere jsem zde zminil.
 
                                                                                                                                        Skuplik Vaclav  L94677
                                                                                                                                        sao@iol.cz