Genaue Dateigröße ermitteln. Wie am besten / schnellsten ?

Es gibt 79 Antworten in diesem Thema, welches 10.621 mal aufgerufen wurde. Der letzte Beitrag (27. März 2021 um 23:08) ist von darkvision.

  • Hat das DOS die Track / Sektor Information an der Stelle schon längst gelesen ?

    Da du eine Datei öffnest: ja. Damit liest du nur Bytes von der Datei selbst ohne Overhead (also z.B. auch keine Ladeadresse).


    Wenn ja, wie komme ich denn dann da ran ?

    Per Direktzugriff auf die entsprechenden Bytes im Directory.

  • Per Direktzugriff auf die entsprechenden Bytes im Directory.

    Ja und wie komme ich da ran ?

    Stell Dir eine CMD-HD vor mit 500+ Files in einer Partition, oder ein SD2IEC mit noch mehr Files (also nicht in einem .Dxx Image).

    Muss ich dann je Laufwerkstyp schauen, wo der Directory Track liegt und dann von dort alle Einträge durchgehen, Sektor für Sektor, bis meine gesuchte Datei gefunden ist ?

    Oder geht das irgendwie eleganter ?

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Da du eine Datei öffnest: ja. Damit liest du nur Bytes von der Datei selbst ohne Overhead (also z.B. auch keine Ladeadresse).

    Moment, das war Quatsch. Ladeadresse wird in dem Fall doch mitgelesen.


    Ja und wie komme ich da ran ?

    Da bin ich, was über 1541 hinausgeht, überfragt.

  • b=b+s:print"bytes:"b

    Wie ich im Posting davor geschrieben habe, müsste es

    b=b+s-1:print"bytes:"b

    heißen.

    s ist der Index auf das letzte verwendet Byte. Da er bei 0 beginnt, wäre die Anzahl der Byte im Sektor s+1, da aber auch die Link-Bytes mitgezählt werden, muss man wieder 2 abziehen -> s-1

  • Ja was lange währt.....

    Funktioniert, ist aber ziemlich lahm. Mal sehen ob ich das ins Terminal einbaue.

    Wie ich im Posting davor geschrieben haben müsste es

    b=b+s-1:print"bytes:"b

    Das hatte ich glatt überlesen und ich wundere mich warum ich ein Byte zuviel im Ergebnis habe :platsch:

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Wie komme ich denn nun an die Information, von Start Track / Sektor ?

    Das Directory mit

    OPEN1,8,2,"$"

    öffnen. Dabei wird das Directory "roh" geliefert und nicht als "BASIC-Programm"...

    Am Anfang kommt die BAM mit Diskname, also das. Da sollte man auch erkennen, was das für ein Disktyp ist.

    Dann folgen die Directory-Einträge zu je 30 Bytes, die zwei Bytes vor den Namen sind dann Start-Track/Sector.

    Der Eintrag ist aufgebaut wie in Bitte melde dich an, um diesen Link zu sehen. beschrieben.

    Wie das bei anderen Gerätetypen mit der BAM-Größe ist, weiß ich nicht so genau, man kann da versuchen adaptiv darüber zu lesen, bis man einen Dir-Eintrag erkennt und dann alle Einträge durchgehen ...

  • Wie komme ich denn nun an die Information, von Start Track / Sektor ?

    Das Directory mit

    OPEN1,8,2,"$"

    öffnen. Dabei wird das Directory "roh" geliefert und nicht als "BASIC-Programm"...

    Eben ausprobiert... klappt tatsächlich. Bei einer CMDHD-1581-Partition kommt nur der BAM-Header mit (1 Block), danach das Verzeichniss.

    Bei Native mit vielen Dateien kann die Suche schon etwas dauern... unter Umständen dauert dann die Suche nach der Datei im Verzeichnis länger als das einfache einlesen der Datei bis zum Ende um die Größe zu ermitteln. Hängt halt von der Dateigröße ab...

  • Mit "sauberen" Directories funktioniert mein Code von gestern Nacht.

    Habe ich aber gescratchte Files, werden zum Teil die zu scannenden Files nicht mehr gefunden.

    Ich suche in Zeile 4 ja zeichenweise aufbauend nach dem Inhalt von f$, also mein Suchfile.

    Liegt mein Suchfile hinter einem oder mehrerem gescratchten Files, wird mind. das erste Zeichen vom Filenamen im Dir nicht mehr richtig ausgelesen und daher das Suchfile niemals gefunden. In Zeile 6 ist dann Ende.

    Haben gescratchte Files ein Byte weniger ? Stehe gerade etwas auf'n Schlauch.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Gescratchte Files, solange diese nicht überschrieben wurden, sind exakt genauso Lang wie ungescratchte.

    So wie ich das gelesen habe, suchst du ein Tool, dass eine oder alle Dateien eines Datenträgers scannt und die Bytegröße der einzelnen Dateien, ohne Adressbytes ausgibt?

  • Hat das DOS die Track / Sektor Information an der Stelle schon längst gelesen ? Wenn ja, wie komme ich denn dann da ran ?

    Erst die Datei normal öffnen, dann mit dem "B-P"-Befehl den Lesezeiger auf Offset 0 setzen, ein Byte lesen, mit "B-P" den Zeiger auf Offset 1 stellen, wieder ein Byte lesen, Datei schließen. Jetzt hat man den ersten Linkpointer und kann die restlichen Blöcke per U1 lesen.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Wie komme ich denn nun an die Information, von Start Track / Sektor ?

    Das Directory mit

    OPEN1,8,2,"$"

    öffnen. Dabei wird das Directory "roh" geliefert und nicht als "BASIC-Programm"...

    Das ist ja spannend. Das kannte ich gar nicht.

    Ich habe habe das dann gleich mal bei einer CBM 4040 probiert. Aber da funktoniert das nicht.

    Und ist dann auch der Grund, warum mir das unbekannt war. ;)

  • So wie ich das gelesen habe, suchst du ein Tool, dass eine oder alle Dateien eines Datenträgers scannt und die Bytegröße der einzelnen Dateien, ohne Adressbytes ausgibt?

    Korrekt.

    Erst die Datei normal öffnen, dann mit dem "B-P"-Befehl den Lesezeiger auf Offset 0 setzen, ein Byte lesen, mit "B-P" den Zeiger auf Offset 1 stellen, wieder ein Byte lesen, Datei schließen. Jetzt hat man den ersten Linkpointer und kann die restlichen Blöcke per U1 lesen.

    Super. Das könnte wesentlich schneller gehen. Probiere ich aus.


    Besteht die Möglichkeit, einen IFFL-Scanner für soetwas zu nutzen. Letzendlich zählt eine Routine dieser Art auch nur Bytes.

    Ja möglich, funktioniert dann aber im BBS wegen Platzmangel nicht mehr. Der IFFL Scannercode müsste ja irgendwo permanent untergebracht werden.

    Der IFFL Scanner müsste dann aber mit allen Laufwerksarten funktionieren. Ggf. sowas wie bei N0SDOS.


    Haben gescratchte Files ein Byte weniger ? Stehe gerade etwas auf'n Schlauch.

    War ja klar... ich mal wieder. Alle Files die nicht mehr auf 18 / 01 stehen werden nicht gefunden. Warum ? Weil die 2 Bytes vom Track / Sektor Link der Directories ja auch mitgelesen bzw. überlesen werden müssen.

    Fettes double

    :platsch::platsch:

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Ich hatte mir doch mal einige Helfer Tools gecodet, zum Erstellen von Anpassungen für Easyflash, REU, Georam und die SCPU.

    Gerade eben gemacht. Die Bilder unten zeigen den "File Linker und Tabellen Maker" beim Einlesen der Buck Rogers 1581-Version und die erstellten Dateien.

    Vielleicht ist das ja was für dich.:)

  • 3 getBitte melde dich an, um diesen Link zu sehen.,a$:getBitte melde dich an, um diesen Link zu sehen.,t$:getBitte melde dich an, um diesen Link zu sehen.,s$:c$=""
    4 forx=3to18:getBitte melde dich an, um diesen Link zu sehen.,a$:c$=c$+a$:if left$(c$,len(c$))=f$ then close8:goto8

    In Z 3 wird der Filetyp gelesen, anhand von a$ sollte man vermeiden überhaupt "gelöschte" Einträge zu überlesen.

    Etwa mit gosub 800

    800 getBitte melde dich an, um diesen Link zu sehen.,a0$,a1$,a2$,a3$,a4$,a5$,a6$,a7$,a8$,a9$,b0$,b1$,b2$,b3$,b4$,b5$:return

    left$(c$,len(c$)) ist sinnlos ... das ist immer c$. Sinn ergäbe eher left$(c$,len(f$)) = f$

    Die Abfrage sollte man aber erst am Ende der forx-Schleife machen. Sonst wird für alle 16 Zeichen (bei allen Files) immer abgefragt. Lieber flott, ohne diese Abfrage den Filenamen zusammensetzen (beim gesuchten File die überhängenden Zeichen zu lesen ist vergleichsweise geringerer Schaden, denn bei *allen* Files diesen Overhead aufzuerlegen.

  • Vielleicht ist das ja was für dich

    Ja gerne.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • left$(c$,len(c$)) ist sinnlos ... das ist immer c$. Sinn ergäbe eher left$(c$,len(f$)) = f$

    Dann könnte man auch IF c$=f$ THEN machen.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Tja, am besten alle :)

    Also 1541, 1571, 1581, CMD-HD / RL, FD-2000 / 4000, SD2IEC, U64 SoftIEC, IDE64, evtl. REU Ramdisk (RAMDOS)

    Damit dürfte man das Wichtigste für den BBS Betrieb abgedeckt haben.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70