Pascal-ban e feladat hogy oldható meg egyszerűen a TFileStream használatával? (én csak simán tudom)

40: Ti osztódással szaporodtok?

[link]

Szegényebbek kedvéért:

"Logical Cluster Number (LCN)

Each cluster in a volume is given a sequential number. This is its Logical Cluster Number. LCN 0 (zero) refers to the first cluster in the volume (the boot sector).

To convert from an LCN to a physical offset in the volume, multiply the LCN by the Cluster Size.

Virtual Cluster Number (VCN)

Each cluster of a non-resident stream is given a sequential number. This is its Virtual Cluster Number. VCN 0 (zero) refers to the first cluster of the stream.

To locate the stream on disk, it's necessary to convert from a VCN to an LCN. This is done with the help of data runs.

Data Runs

Each contiguous block of LCNs is given a Data Run, which contains a VCN, an LCN and a length. When NTFS needs to to find an object on disk, it looks up the VCN in the Data Runs to get the LCN. "

Te érted félre.

Én eddig is azt mondtam, hogy egy bejegyzés egy clusterre mutat (a sok helyettt, amit állítasz te is és a másik válaszoló is).

Az a baj, hogy az NTFS szerkezetét ugyanúgy nem érted, ahogy a FAT-ét sem.

Az NTFS esetén minden dolog FILE. Ez téveszt meg téged. Javaslom, olvass utána.

Azt továbbra is fenntartom (még szép, hiszen így is van), hogy a FAT-hoz hasonlóan, az NTFS és más népszerűbb file-rendszerek is láncolt listát alkalmaznak az adatok eléréséhez, ahogy azt is, hogy a FAT táblában, MFT-ben csak és kizárólag az első cluster indexére történik hivatkozás. A többi cluster indexének eredője ez az egy. Mivel mind a FAT, mind az NTFS bejegyzései publikusak, továbbá, mivel ezek nem tartalmaznak egyéb cluster indexet, így teljesen logikus, hogy a további indexek csakis az adatterületeken helyezkedhetnek el. Persze ez nem csak logikus, hanem valójában így is van.

Az NTFS egy elég bonyolult rendszer, azt megérteni nem egyszerű, így javasolm, hogy a hozzá logikailag legközelebb álló ext2 filerendszer szerkezetét tanulmányozd. A kulcsszó a NODE. Szerintem meg fogod érteni és el is fogod fogadni azt, amit korábban erről írtam, hogy miért lehet olyan gyors a nagy file-ok végére seekelés, annak ellenére, hogy az adatok között vannak a clusterek indexei eltárolva.

"így teljesen logikus, hogy a további indexek csakis az adatterületeken helyezkedhetnek el."

Na, itt van az amiben tévedsz.

A FAT esetében van egy mutató az első clusterre és a FAT táblában annyi bejegyzés van ahány cluster. Minden bejegyzés a következő clusterre mutat. 2 kitüntetett érték van: Üres és a File vége.

NTFS esetén pedig data run-ok vannak amik nem egyesével mutatnak a clusterekre, hanem csak a egymás utániakra. Illetve mindegyikhez meg van adva, hogy hány egymás utáni clustert kell nézni.

Tehát egyik esetben sem az adatok végén van a mutató a következőre.

Lehet, hogy neked megérteni ezt nem egyszerű, ezt nem vitatom.

"A FAT-tel formázott rendszer fürtökre van osztva, tehát a kezelő szoftver egy bejegyzést tesz a gyökérkönyvtárba, melyben szerepelteti az első szelet helyét és a szeletek számát. Magában a szeletekben pedig a szelet végén mindig a következő szelet eleje van."

"Ebben az esetben (a szabad területek nyilvántartásánál már megismert

módon) a tárolás szekvenciális és mindig a sor elejéről indul, oly módon, hogy

maga a blokk tartalmazza a következő blokk számát, ami hasznos területet

vesz el a blokkból. A nyilvántartáshoz a fájlok első és utolsó blokkjának

sorszámát elegendő tárolni."

"Ebben az esetben minden egyes szabad blokk utolsó néhány bájtját kiemeljük

a klasszikus adattárolási funkcióból, ugyanis ezen a néhány bájton a

következő szabad blokk sorszámát tároljuk."

Ebből talán megvilágosulsz (NODE):

"Ebben az esetben egy szabad blokk nem csak egy, a soron következő blokk

címét tartalmazza, hanem „n” darab blokk címét, melyek közül „n-1” darab

ténylegesen szabad, hiszen az „n.” blokk már maga is egy újabb

címgyűjtemény. Azaz ciklikusan egy teljes blokkot a nyilvántartás céljaira

foglalunk le. Teljesítménye, hatékonysága jobb, mint a blokkok láncolt

listájának hasonló paraméterei."

Ezt te írtad:

"2 kitüntetett érték van: Üres és a File vége."

Hogyne. Meg reserved, meg BAD sector (cluster), meg még vagy öt másik.

program FileForWrite;

{$mode delphi}

uses classes;

var

 MyFS: TFileStream;

 Ch: Char;

begin

  MyFS := Tfilestream.Create('myFile.txt', fmCreate or fmOpenReadWrite);

  Ch := 'A';

  try

  MyFS.WriteBuffer(Ch,1);

  MyFS.WriteBuffer(Ch,1);

  Finally

  MyFs.Free;

  end;

end.

Te még mindig olyanokat másolsz de, ami az üres szektorokról szól.

"Hogyne. Meg reserved, meg BAD sector (cluster), meg még vagy öt másik."

Na most buktál le, mert tényleg van reserved és BAD cluster, de ha a fileok lennenek láncolva egymás után, miért lenne? mutat egy file a kovetkezo cluseterre ami a bad cluster azonositoja?:D semmi értelme nem lenne. Akkor csak következő cluster és end marker lenne.

Nem hiszem, hogy ennyie nem vagy képben alapveto adaszerkezetekkel, inkább csak kötekedsz és félsz belátni, hogy nincs igazad.

FAT16/32 esetében:

A Fat tablaban annyi bejegyzes van (+/-100 hogy ne tudj belekötni az állításomba:)), ahany cluster, mindegyik bejegyzes vagy available, vagy reserverd vagy bad cluter vagy end marker....vagy pedig mutat a kovetkező clusterre.. nincs még +5 ahogy írod..., sőt még +1 sem.

exFAT-nél még van egy "media descriptor" is, mielőtt ezzel jössz.

Az adatok (file tartalma) pedig nem itt vannak:)