Pascal-ban e feladat hogy oldható meg egyszerűen a TFileStream használatával? (én csak simán tudom)
Ha például látrehozok egy fájlt, beleírok 2 karaktert, bezárom, majd ismét megnyitom és a két karakter közé szeretnék írni egy harmadikat, de nem úgy hogy felülíroma karaktert ami ott van, hanem egy harmadik karakter kerül a 2 közé a fájlba...
program filesproba;
var
f : file of char;
ch : char;
begin
assign(f, 'probafile');
rewrite(f);
ch := 'A';
Write(f,ch);
Write(f,ch);
close(f);
end.
válasza:"de nem úgy hogy felülíroma karaktert ami ott van, hanem egy harmadik karakter kerül a 2 közé a fájlba..."
Hát így nem fog menni. Az utolsó karaktert pufferelni kell, az újjal felülírni és amögé visszaírni a puffer tartalmát.
A file-ok szekvenciális elérésű adathalmazok, tehát nincs lehetőség arra, hogy adatokat arrébb pöckölve beszűrjunk újakat bárhova.
Csak a kiolvasás segít majd a visszaírás.
Ez direkt fájlkezelés, már abból a szempontból, hogy nem kell feltétlenül "eljétől végéig végigolvasni" bárhova ugorhatok a fájlban, nemcsak sorban olvashatok adatokat.
Mondjuk az igaz, hogy nem lehet "odébbtenni" adatot.
válasza:"már abból a szempontból, hogy nem kell feltétlenül "eljétől végéig végigolvasni" bárhova ugorhatok a fájlban, nemcsak sorban olvashatok adatokat."
Ez nem egészen így van.
A file kezelését az opre végzi. Az csak szekvenciálisan fér hozzá az adatokhoz, de amikor te kéred mondjuk a hatodik blokkot, rekordot, akkor neked csak azt adja, de ő előtte már végiggurult az előző ötön, hogy hozzáférjen a hatodikhoz. Csak te ezt nem látod.
válasza:" de ő előtte már végiggurult az előző ötön, hogy hozzáférjen a hatodikhoz. Csak te ezt nem látod."
Ez hülyeség, ha megnyitsz egy több terrabyteos filet és seekelsz a végére, nem fogja végigolvasni.
válasza:"Ez hülyeség, ha megnyitsz egy több terrabyteos filet és seekelsz a végére, nem fogja végigolvasni."
Ne legyél már te ennyire "okos".
válasza:Bocs, csak a tényeket írtam le, tapasztalatból. Elnézést a gépelési hibáért (terabyte).
Nálunk van 3+ TB-os file és simán meg lehet nézni a végét anélkül, hogy várnánk kb. 10 percet mire végigolvasná az SSD amin található (nyilván fizikailag több eszköz RAID-be kötve).
De te magad is kipróbálhatod mezei HDD-n/SSD-n pár GB-os fájllal, ott is szembetűnő (ha nem is 10 perc) különbség van.
válasza:Ne is haragudj, de Te nem a tényeket írtad le, csak egy észlelésből eredő vélekedésedet, amely a tényekkel nincs semmiféle kapcsolatban.
A valóság ez:
A file rendszerek (Pl. FAT) úgy tárolják az adatokat, hogy
van egy FAT tábla, ebben van a file-ok neve és egy szám, amely arra clusterre mutat az adattárolón, ahol a file kezdődik. A clusterek rögzített hosszíságú tároló egységek, a FAT esetében ez (!) alapban 512 byte.
A HDD kiolvassa a file kezdő pozícióját, ráseekel, végigolvassa az 512 byte-ot, amelyből 510 a file eleje, és 2 byte ami a következő clusterre mutat. Ezt a két byte-ot is kiolvassa a HDD majd ráseekel a clusterre és ujból kiolvas 510 byte adatot, majd ezt követi megint 2 byte ami a köv. cluster számát jelzi és így tovább, amíg EOF-ot nem olvas.
Természetesen modernebb file rendszereken a cluster mérete nem csak 512 byte, hanem 64 kbybte is lehet, vagy ennél is nagyobb egység. De az biztos, hogy a file végét csak akkor képes elérni a rendszer, ha előtte végignyálazta a file többi részét is, hiszen a file-hoz tartozó összes cluster címe nem tárolható le az alllokációs táblában.
Vannak persze speckó file rendszerek, amelyek arra vannak kiképezve, hogy a file "közepét, végét" is hamar elérjék, ilyenek az adatbázisok file rendszerei és más speciális igényekre tervezett rendszerek, de itt is igaz amit írtam feljebb, csak itt trükkökkel oldják meg a gyorsabb elérést. Ami pl. abban nyilvánul meg, hogy amit te egy file-nak látsz, az valójában több tíz, vagy több száz. Na meg, a beszúrás művelete úgy történik, hogy a file végére van írva az új adat és csak akkor kerül a helyére, ha az adatbázis kezelő ráér. Addig pedig a rendszer úgy láttatja veled, hogy a beszúrt rekord a helyén van, nem pedig a file végén.
(!) A FAT filerendszerek esetében sem feltétlenül 512 byte egy cluster (inkább ennek többszöröse, vagy opcionális), de ez a legkisebb egység, ami egyáltalán lehet.
Ennél kevesebbet a HDD NEM KÉPES elolvasni.
válasza:Nem tudom honnan veszed ezeket a hülyeségeket, de már FAT16 esetén sem így volt. Nem a cluster végén van egy 2 byteos mutató a következő clusterre.
Nem kétlem, hogy a Commodore-os floppys időkben valami hasonló volt, de az elmúlt 30 évben már biztos nem.
Gondolj csak bele, ha így lenne, és a cluster végén lenne 2 (4-8) byte ami a következő clusterre mutat, akkor tényleg végig kellene olvasni az egész fájlt, és HDD-n ez még problémásabb, mint SSD-n ha töredezett a file. Mondjuk te pont ezt állítod, de ez nonszensz.
Az hogy hogyan következnek a clusterek egymás után FAT fájlendszer esetén a FAT-ben találhatóak. Itt nincs fálj tartalom adat (amit te 510 byteak írtál), csak mutatók a következő clusterre.
Én csak annyit tudok erről, hogy "láncolt listában" történik az adatok tárolása a merevlemezen.
FPC Wiki-n kívül honnan tudhatnám meg, hogy hányféleképpen használható a TFileStream, bele kellene néznem valami forráskódba?
Fájl-létrehozást, bezárást már tudom, tudom hogy TFileStream.position a pozíciót adja vissza, a TFileStream.size a méretet, ezenkívül milyen más van még?
válasza:Read
Seek
Write
Derived from TStream
CopyFrom
FixupResourceHeader
ReadBuffer
ReadComponent
ReadComponentRes
ReadResHeader
WriteBuffer
WriteComponent
WriteComponentRes
WriteDescendent
WriteDescendentRes
WriteResourceHeader
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!