MichiLee: Linux Ordnerrechte

Hallo Forum,
ich bin es mal wieder.

Unser Prof. schreibt, sobald für ein Ordnerrechte (Gruppe) rw gesetzt ist, und ich als angehöriger der Gruppe nun eine Datei (ebenfalls rw) aus dem benannten Ordner löschen will, dass dies nicht funktioniert, da das x für den Ordner fehlt. Kann dies leider nicht testen, da ich keine Linuxkiste habe.

Mit rw für Ordner kann ich zwar nicht in den Ordner wechseln, aber könnte doch von außen Lesen, welche Dateien (drin sind) und könnte doch von außen auch neue Dateien anlegen, bearbeiten und löschen. (Sobald bei der Datei das w gesetzt ist?

Auch dürfte ein Zwischenordner mit überhaupt keinen Berechtigungen für mich ja kein Hinderniss sein, wie zum Beispiel /zwischen/meinOrdner

Ne kleine Frage nochmals zur FAT-Berechnung, da ich dies im letzten Thread nicht beendet habe.
Blockgröße ist mir nun klar. Das wäre, wie groß ein einzelner Block, bzw. Speicherbereich ist. Bsl. 8KB oder 32KB und 1GB Partitionsgröße.

Anzahl Einträge bzw. Anzahl Blöcke erhalte ich nun durch:
1GB Partitionsgröße / 1KB Blockgröße = 2^20 / 1 = 2^20 = ca. 1 Million Einträge/Blöcke

Um nun die FAT-Gräße zu berechnen, muss ich Zeigerlänge (Länge des Blocks laut Prof) * Blockanzahl machen.

Ist5 die Zeigerlänge die Anzahl der Bits, die man für die Adressierungen für die 1 Million Blocke braucht? Das wäre dann 20.

Hieße dann als FAT-Größe 2^20 * 20 bit = 2.5MB
Richtig? Hört sich schonmal gut an. Ich vermute mal, dass die 20 Zeigerlänge dann auch die FAT repräsentiert, also in diesem Beispiel FAT20. Wobei es jetzt sicherlich kein FAT20 gibt. In meiner Rechnung müsste ich dann 32 als Zeigerlänge nehmen)

Was mich jedoch irritiert, dass noch die Wörter Cluster bzw. Sektoren genannt wurden. Was ist darunter zu verstehen?
Wenn ich mich richtig erinnere, hat er Cluster 16, 8KB Blockgröße = 512MB FAT FAT16 oder FAT32 Größe. Dann hatte er eben verschiedene Cluster/Sektoren Angaben, von 1 bis 64. Was ist nun ein Cluster und wie fließt dies in die Rechnung rein?

Warum wären bei Netzwerke der Layer2 unsicher? Bzw. Switche?

Als nächstes muss ich das Bankiers-Algorhytmus lernen, hoffentlich finde ich da etwas anschauliches, außer das von Wiki :-)

Viele viele Grüße

  1. Hi,

    ich bin es mal wieder.

    ja, langsam ist mir der Name geläufig. ;-)

    Ne kleine Frage nochmals zur FAT-Berechnung, da ich dies im letzten Thread nicht beendet habe.
    Blockgröße ist mir nun klar. Das wäre, wie groß ein einzelner Block, bzw. Speicherbereich ist. Bsl. 8KB oder 32KB und 1GB Partitionsgröße.
    Anzahl Einträge bzw. Anzahl Blöcke erhalte ich nun durch:
    1GB Partitionsgröße / 1KB Blockgröße = 2^20 / 1 = 2^20 = ca. 1 Million Einträge/Blöcke

    Soweit kann ich noch folgen.

    Um nun die FAT-Gräße zu berechnen, muss ich Zeigerlänge (Länge des Blocks laut Prof) * Blockanzahl machen.
    Ist5 die Zeigerlänge die Anzahl der Bits, die man für die Adressierungen für die 1 Million Blocke braucht? Das wäre dann 20.

    Nein. FAT kennt nur entweder 12 oder 16 oder 32bit als Blocknummer (Clusternummer).

    Hieße dann als FAT-Größe 2^20 * 20 bit = 2.5MB
    Richtig? Hört sich schonmal gut an. Ich vermute mal, dass die 20 Zeigerlänge dann auch die FAT repräsentiert, also in diesem Beispiel FAT20.

    Nö. Das ist blanke Theorie.

    Wobei es jetzt sicherlich kein FAT20 gibt. In meiner Rechnung müsste ich dann 32 als Zeigerlänge nehmen)

    So ist es. Da FAT16 mit 16bit nicht reicht, muss es FAT32 sein, also 32bit für jeden Eintrag.

    Was mich jedoch irritiert, dass noch die Wörter Cluster bzw. Sektoren genannt wurden. Was ist darunter zu verstehen?

    Cluster ist in der ursprünglichen Microsoft-Terminologie das, was du als Block bezeichnest. Ein Cluster ist ein Verbund von 2^n Sektoren, der maximal 64kB groß werden kann (bis Windows 95 nur 32kB).

    Wenn ich mich richtig erinnere, hat er Cluster 16, 8KB Blockgröße = 512MB FAT FAT16 oder FAT32 Größe. Dann hatte er eben verschiedene Cluster/Sektoren Angaben, von 1 bis 64. Was ist nun ein Cluster und wie fließt dies in die Rechnung rein?

    Hä? Ein Sektor ist bei FAT-Dateisystemen normalerweise 512 Byte. Nur um die Verwaltung zu vereinfachen, werden 2^n Sektoren zu einem Cluster zusammengefasst.

    Als nächstes muss ich das Bankiers-Algorhytmus lernen

    Was soll das sein? Als erstes solltest du dir vielleicht die korrekt Schreibweise des Wortes Algorithmus einprägen.

    Ciao,
     Martin

    --
    Es gibt Dinge, die sind sooo falsch, dass nicht einmal das Gegenteil stimmt.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hallo,

      ich habe nochmals das Script nachgeschlagen.

      Bei heutigen Festplatten ist ein Sektor (Unterteilung einer Spur in sektoren) 512 Byte groß.
      (D.h., dass ein Sektor hardwarebezogen ist?)

      Speicherblöcke von Dateisysteme fassen typ. 512  32786 Bytes.
      Speicherblockgröße = Clustergröße.

      (Daraus schließe ich, dass unser Prof. einen Block auch Cluster nennt)

      Nun gibt es eine Tabelle:
      Sektoren/Cluster Blockgröße    FAT12   FAT16   FAT32
      1                  0.5KB        2MB
      2                  1KB          4MB
      4                  2KB          8MB    128MB
      8                  4KB          16MB   256MB    1TB
      16                 8KB                 512MB    2TB
      32                 16KB                1024MB   2TB
      64                 32KB                2048MB   2TB

      1. Was meint er nun mit der Spalte "Sektoren/Cluster"? Dass er in 1,2,4 Speicherblöcke hat?

      2. Zitat: "Es können max. 2^16 I-Nodes referenziert werden. Also nur 2^16 Dateien pro Dateisystem"
      D.h. das Dateisystem hat 65536 I-Nodes. (Ein I-Node hat 12 direkte Zeiger auf 1KB große Cluster, und dann einfach,zweifach, dreifach indirekte.
      Habe ich dann richtig verstanden, dass eine einfach indirekte Blockadresse im I-Node, auf ein neues I-Node im Speicherblock zeigt?
      Das würde heißen, dass die I-Nodes größer als 65536 dann dynamisch wachsend im Speicherblock liegen, anstatt im Dateisystem oder werden die auch gleich angelegt?

      3. Wie errechnet man, dass ein I-Node im 1KB großen Speicherblock 256 Adressen haben kann? (2^32 Bit Adressraum)?

      Was soll das sein? Als erstes solltest du dir vielleicht die korrekt Schreibweise des Wortes Algorithmus einprägen.

      Oh ja. Bankiers Algorithmus. Anscheinend kommt dies aber nicht dran, wie ich erfahren habe. Für das Allgemeinwissen wäre dies sicherlich auch nicht unbedingt notwedig :-)

      Grüße

      1. Hi,

        Bei heutigen Festplatten ist ein Sektor (Unterteilung einer Spur in sektoren) 512 Byte groß. (D.h., dass ein Sektor hardwarebezogen ist?)

        <RadioEriwan>im Prinzip ja.</RadioEriwan>
        Natürlich kann man das theoretisch verändern, indem man eine Low-Level-Formatierung durchführt. Das ist aber bei den heutigen Festplatten nur noch für den Hersteller möglich, denn es braucht spezielle Software und viel Detailwissen über die Festplatte.

        Speicherblockgröße = Clustergröße.
        (Daraus schließe ich, dass unser Prof. einen Block auch Cluster nennt)

        Vernünftig, weil das ein seit vielen Jahren üblicher Begriff ist.

        Nun gibt es eine Tabelle:
        Sektoren/Cluster Blockgröße    FAT12   FAT16   FAT32
        1                  0.5KB        2MB
        2                  1KB          4MB
        4                  2KB          8MB    128MB
        8                  4KB          16MB   256MB    1TB
        16                 8KB                 512MB    2TB
        32                 16KB                1024MB   2TB [4TB]
        64                 32KB                2048MB   2TB [8TB]

        1. Was meint er nun mit der Spalte "Sektoren/Cluster"? Dass er in 1,2,4 Speicherblöcke hat?

        Ja: Sektoren pro Cluster. Muss eine Zweierpotenz sein (Vorgabe vom OS).
        Typische Werte sind:
           1 Sektor/Cluster (0.5k)    FAT12  HD-Disketten (1.20, 1.44, 1.60 oder 1.68MB)
           2 Sektoren/Cluster (1k)    FAT12  DD-Disketten (720kB und kleiner)
           8 Sektoren/Cluster (4k)    FAT16  HDD-Partitionen (hochgradig kompatibel)
        ab 8 Sektoren/Cluster (4k)    FAT32  HDD-Partitionen

        FAT16- und FAT32-Partitionen mit kleineren Clustern als 8 Sektoren (4k) sind möglich, aber ungewöhnlich. Die maximale Partitionsgröße bei FAT32 ist übrigens nicht 2TB, sondern je nach Clustergröße bis zu 8TB, ich hab's in der obigen Tabelle in eckigen Klammern ergänzt.
        Eigentlich sollte man annehmen, dass bei 32k Clustergröße sogar 32k * 2^32 = 128TB möglich wären. Die Implementierung des FAT32-Treibers von Microsoft nutzt aber nur 28 von 32bit, dadurch ist die maximale Clusteranzahl um den Faktor 16 kleiner.

        1. Zitat: "Es können max. 2^16 I-Nodes referenziert werden. Also nur 2^16 Dateien pro Dateisystem"

        Jetzt geht's offensichtlich nicht mehr um FAT, sondern um Unix-Dateisysteme.
        Da bin ich nicht genügend mit der Materie vertraut, als dass ich das kommentieren könnte.

        1. Wie errechnet man, dass ein I-Node im 1KB großen Speicherblock 256 Adressen haben kann? (2^32 Bit Adressraum)?

        Indem man 1kB = 1024Byte durch 32bit = 4Byte dividiert.

        Als erstes solltest du dir vielleicht die korrekt Schreibweise des Wortes Algorithmus einprägen.
        Oh ja. Bankiers Algorithmus.

        Genau. Und bitte nicht mit dem Logarithmus oder gar dem Rhythmus verwechseln. ;-)

        Ciao,
         Martin

        --
        Soso, der Klügere gibt nach.
        Aber warum sollen sich immer nur die Dummen durchsetzen?  .oO(?)
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. Hi,

          Bei heutigen Festplatten ist ein Sektor (Unterteilung einer Spur in sektoren) 512 Byte groß. (D.h., dass ein Sektor hardwarebezogen ist?)

          <RadioEriwan>im Prinzip ja.</RadioEriwan>

          Dieser angeblicher Radiosender hört sich cool an :-)

          Nun gibt es eine Tabelle:
          Sektoren/Cluster Blockgröße    FAT12   FAT16   FAT32
          1                  0.5KB        2MB
          2                  1KB          4MB
          4                  2KB          8MB    128MB
          8                  4KB          16MB   256MB    1TB
          16                 8KB                 512MB    2TB
          32                 16KB                1024MB   2TB [4TB]
          64                 32KB                2048MB   2TB [8TB]

          Ja: Sektoren pro Cluster. Muss eine Zweierpotenz sein (Vorgabe vom OS).
          Typische Werte sind:
             1 Sektor/Cluster (0.5k)    FAT12  HD-Disketten (1.20, 1.44, 1.60 oder 1.68MB)
             2 Sektoren/Cluster (1k)    FAT12  DD-Disketten (720kB und kleiner)
             8 Sektoren/Cluster (4k)    FAT16  HDD-Partitionen (hochgradig kompatibel)
          ab 8 Sektoren/Cluster (4k)    FAT32  HDD-Partitionen

          Ah, Salte 1 und 2 stehen in Bezug. Also ein Sektor (physisch - hardware) wird vom Dateisystem als Anhaltspunkt genommen.
          Man nimmt man dann Beispiel 8 Sektoren zu je 512 Bytes zu einem Block/Cluster, was dann die 4KB ergibt. Jetzt erst hat es Klick gemacht, sorry :-)
          Interessant,dass man bei FAT16 64 Sektoren/Cluster max. eine Partition mit 2GB haben konnte. (So lange liegt ja Win98 auch nicht zurück. Hatte ich damals so eine kleine Platte :-) )

          1. Zitat: "Es können max. 2^16 I-Nodes referenziert werden. Also nur 2^16 Dateien pro Dateisystem"

          Jetzt geht's offensichtlich nicht mehr um FAT, sondern um Unix-Dateisysteme.
          Da bin ich nicht genügend mit der Materie vertraut, als dass ich das kommentieren könnte.

          Danke trotzdem für all die anderen Antworten. Vielleicht meldet sich bzgl. I-Nodes noch ein anderer Fachmann.

          1. Wie errechnet man, dass ein I-Node im 1KB großen Speicherblock 256 Adressen haben kann? (2^32 Bit Adressraum)?

          Indem man 1kB = 1024Byte durch 32bit = 4Byte dividiert.

          Stimmt, danke :-)

          Als erstes solltest du dir vielleicht die korrekt Schreibweise des Wortes Algorithmus einprägen.
          Oh ja. Bankiers Algorithmus.

          Genau. Und bitte nicht mit dem Logarithmus oder gar dem Rhythmus verwechseln. ;-)

          Ich habe leider oft Deadlocks, meine Gehirnzellen takten öfters wie ein alter AMIGA und vergisst auch immer wieder mal bestimmte Speicherzellen. Liegt vermutlich auch daran, dass ich überall (in vielen Themen) meine Nase drin habe.

          Grüße

          1. Hallo,

            <RadioEriwan>im Prinzip ja.</RadioEriwan>
            Dieser angeblicher Radiosender hört sich cool an :-)

            sag bloß, das war dir nicht geläufig ...

            Interessant,dass man bei FAT16 64 Sektoren/Cluster max. eine Partition mit 2GB haben konnte.

            Ja, einige DOS-Versionen konnten auch mit 128 Sektoren (also 64kB) pro Cluster umgehen und so gigantische 4GB große Partitionen verwalten. Das war aber ein Glücksspiel, denn viele FAT16-Implementierungen verwendeten nur 16bit bei der Berechnung der Clustergröße, bekamen durch den dann auftretenden Überlauf 0 heraus und fielen böse auf die Schnauze.

            (So lange liegt ja Win98 auch nicht zurück. Hatte ich damals so eine kleine Platte :-) )

            Windows 98 hatte ja auch kein Problem mehr mit richtig großen Platten; selbst Windows 95 hatte ab Version 2.0 schon FAT32-Support (und die Versionen davor wollte man sowieso nicht verwenden). Für Systeme, die FAT32 nicht "können", muss man bei MS also entweder bis zur Urversion von Windows 95 zurückgehen, oder zu NT4.

            Ciao,
             Martin

            --
            Es sagte...
            ein korpulenter Lehrer zu einem Schüler, der ihn ein Fass genannt hatte: "Nein. Ein Fass ist von Reifen umgeben, ich dagegen von Unreifen."
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. Hallo Martin,

              Windows 98 hatte ja auch kein Problem mehr mit richtig großen Platten; selbst Windows 95 hatte ab Version 2.0 schon FAT32-Support

              genauer ab Windows 95b, ...

              (und die Versionen davor wollte man sowieso nicht verwenden). Für Systeme, die FAT32 nicht "können", muss man bei MS also entweder bis zur Urversion von Windows 95 zurückgehen,

              nein, der Nachfolger der Urversion von Windows 95, Windows 95a hatte auch noch keinen FAT32-Support.

              oder zu NT4.

              Freundliche Grüße

              Vinzenz

              1. Hallo,

                Windows 98 hatte ja auch kein Problem mehr mit richtig großen Platten; selbst Windows 95 hatte ab Version 2.0 schon FAT32-Support
                genauer ab Windows 95b, ...

                sag ich doch. Was landläufig "Windows 95b" genannt wurde, hieß korrekt "Windows 95 OEM Service Release (OSR) 2.0".

                (und die Versionen davor wollte man sowieso nicht verwenden). Für Systeme, die FAT32 nicht "können", muss man bei MS also entweder bis zur Urversion von Windows 95 zurückgehen,
                nein, der Nachfolger der Urversion von Windows 95, Windows 95a hatte auch noch keinen FAT32-Support.

                Oops, stimmt.

                Ciao,
                 Martin

                --
                Zwei Kumpels sitzen vor dem Computer. "Welche Suchmaschine beutzt du eigentlich meistens?" - "Prima Vera." - "Hmm, kenn' ich gar nicht." Dann geht die Tür auf: "Schatz ich habe deine Sonnenbrille wiedergefunden!" - "Prima, Vera!"
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            2. Hi,

              <RadioEriwan>im Prinzip ja.</RadioEriwan>
              Dieser angeblicher Radiosender hört sich cool an :-)

              sag bloß, das war dir nicht geläufig ...

              Nein, geläufig war es mir nicht. Habe dann in der Wiki gelesen und hört sich doch sehr witzig an :-)

              Interessant,dass man bei FAT16 64 Sektoren/Cluster max. eine Partition mit 2GB haben konnte.

              Ja, einige DOS-Versionen konnten auch mit 128 Sektoren (also 64kB) pro Cluster umgehen und so gigantische 4GB große Partitionen verwalten. Das war aber ein Glücksspiel, denn viele FAT16-Implementierungen verwendeten nur 16bit bei der Berechnung der Clustergröße, bekamen durch den dann auftretenden Überlauf 0 heraus und fielen böse auf die Schnauze.

              Genau, man könnte noch 128 Sektoren pro Cluster nehmen. Den Überlauf habe ich jedoch nicht ganz verstanden. (Wird jetzt aber sicherlich nicht wichtig sein, wie es zum Überlauf kommt)

              Grüße

              1. Hallo,

                Ja, einige DOS-Versionen konnten auch mit 128 Sektoren (also 64kB) pro Cluster umgehen und so gigantische 4GB große Partitionen verwalten. Das war aber ein Glücksspiel, denn viele FAT16-Implementierungen verwendeten nur 16bit bei der Berechnung der Clustergröße, bekamen durch den dann auftretenden Überlauf 0 heraus und fielen böse auf die Schnauze.
                Genau, man könnte noch 128 Sektoren pro Cluster nehmen. Den Überlauf habe ich jedoch nicht ganz verstanden.

                dann versuch mal, die Clustergröße in Byte als Zahlenwert 65536 = 2^16 in 16bit darzustellen ...

                Ciao,
                 Martin

                --
                Nein, es ist nicht wahr, dass bei der Post Beamte schneller befördert werden als Pakete.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                1. Hi,

                  dann versuch mal, die Clustergröße in Byte als Zahlenwert 65536 = 2^16 in 16bit darzustellen ...

                  ehm, ich sollte vielleicht anmerken, dass ich kein reines Informatikstudium absolviere :-)

                  64KB = 65536B pro Cluster
                  Wenn ich nun 2^16 Bits zur Adressierung von 4GB Partition hätte mit 64KB Clustergröße, dann dürfte das genau hinhauen. (Außer, dass ich jetzt schlafen gehen sollte und etwas ganz entscheidendes übersehe/ignoriere)
                  Wobei man von den 4GB noch das Dateisystem abziehen muss, welches für die Verwaltung gebraucht wird.
                  (Ich lass mir das morgen gegen Mittag durch den Kopf nochmals gehen)

                  Grüße und einen schönen Abend an Alle

                2. Hi,

                  Ja, einige DOS-Versionen konnten auch mit 128 Sektoren (also 64kB) pro Cluster umgehen und so gigantische 4GB große Partitionen verwalten. Das war aber ein Glücksspiel, denn viele FAT16-Implementierungen verwendeten nur 16bit bei der Berechnung der Clustergröße, bekamen durch den dann auftretenden Überlauf 0 heraus und fielen böse auf die Schnauze.
                  Genau, man könnte noch 128 Sektoren pro Cluster nehmen. Den Überlauf habe ich jedoch nicht ganz verstanden.

                  dann versuch mal, die Clustergröße in Byte als Zahlenwert 65536 = 2^16 in 16bit darzustellen ...

                  irgendwie bin ich blöd, dumm, was den Überlauf betrifft

  2. Hallo,

    Unser Prof. schreibt, sobald für ein Ordnerrechte (Gruppe) rw gesetzt ist, und ich als angehöriger der Gruppe nun eine Datei (ebenfalls rw) aus dem benannten Ordner löschen will, dass dies nicht funktioniert, da das x für den Ordner fehlt.

    Ja, das ist in der Tat so:

    ~/tmp/rightstest $ ls -la
    insgesamt 12
    drwxr-xr-x  3 christian users 4096 30. Jun 22:51 .
    drwxr-xr-x 27 christian users 4096 30. Jun 22:51 ..
    drw-r--r--  2 christian users 4096 30. Jun 22:52 testverzeichnis

    Du siehst: In dem Verzeichnis gibt's ein Unterverzeichnis mit dem Namen 'testverzeichnis', das keine 'x'-Rechte hat. Wenn ich nun versuchen will, ein Verzeichnislisting zu erstellen, dann sehe ich das folgende:

    ~/tmp/rightstest $ ls -la testverzeichnis
    ls: Zugriff auf a/e nicht möglich: Keine Berechtigung
    ls: Zugriff auf a/b nicht möglich: Keine Berechtigung
    ls: Zugriff auf a/d nicht möglich: Keine Berechtigung
    ls: Zugriff auf a/.. nicht möglich: Keine Berechtigung
    ls: Zugriff auf a/c nicht möglich: Keine Berechtigung
    ls: Zugriff auf a/. nicht möglich: Keine Berechtigung
    insgesamt 0
    d????????? ? ? ? ?             ? .
    d????????? ? ? ? ?             ? ..
    -????????? ? ? ? ?             ? b
    -????????? ? ? ? ?             ? c
    -????????? ? ? ? ?             ? d
    d????????? ? ? ? ?             ? e

    Man kann also anzeigen lassen, welche Dateien in dem Verzeichnis enthalten sind, man kann aber keinerlei Informationen über diese Dateien holen. (Außer die Tatsache, um was für einen Typ Eintrag es sich handelt, also Datei, Verzeichnis, Link, Named Pipe, Char Device, Block Device, ...) Es geht noch weiter: Dateien in dem Verzeichnis kann man auch nicht auslesen und auch nicht in diese Dateien schreiben. Man kann außerdem auch keine Dateien anlegen oder löschen. Das 'w'-Recht ist hier also ohne das 'x'-Recht völlig überflüssig und hat keinerlei Wirkung. Das 'r'-Recht erlaubt einem zumindest noch, ein Verzeichnislisting zu erhalten - mehr aber nicht.

    Mit rw für Ordner kann ich zwar nicht in den Ordner wechseln, aber könnte doch von außen Lesen, welche Dateien (drin sind)

    Ja, das geht, s.o.

    und könnte doch von außen auch neue Dateien anlegen, bearbeiten und löschen. (Sobald bei der Datei das w gesetzt ist?

    Nein, das geht nicht. Das liegt daran, dass man für diese Operationen implizit in das Verzeichnis wechseln können muss ('x'-Recht), was nicht gegeben ist.

    Auch dürfte ein Zwischenordner mit überhaupt keinen Berechtigungen für mich ja kein Hinderniss sein, wie zum Beispiel /zwischen/meinOrdner

    Nein, das wird Dir auch untersagt.

    Verzeichnisrechte ohne 'x' macht man im Normalfall eigentlich nie. Mir fällt auch auf Anhieb nichts ein, wozu man das gebrauchen könnte - aber vmtl. gibt's Spezialfälle, wo das doch irgendwie sinnvoll ist.

    Was aber z.B. problemlos möglich und in manchen Fällen auch nützlich ist, ist Verzeichniss mit 'x'-Recht aber ohne 'r'-Recht auszustatten. Damit kann man dann nicht sehen, welche Dateien in einem Verzeichnis drin sind - wenn man aber einen speziellen Dateinamen kennt, kann man die Datei dann dennoch auslesen oder in sie schreiben - mit gesetztem 'w'-Recht kann man auch Dateien anlegen und löschen.

    Viele Grüße,
    Christian

    PS: Wenn Du Linux haben willst, dann lade Dir VirtualBox herunter und installiere Dir irgend eine Linux-Distro (z.B. Kubuntu) in dieser virtuellen Maschine. Ist dann zwar in der VM nicht so schnell wie direkt auf dem Rechner, aber Du kannst problemlos rumspielen ohne zu große Angst haben zu müssen, etwas kaputt zu machen.

    1. Hi,
      danke für die Ausführliche Antwort. Ich hatte gestern http://wiki.ubuntuusers.de/rechte gelesen und von daher dachte ich, dass bei ein "w" auf ein verzeichnis bedeutet, dass man Dateien/Ordner anlegen, bearbeiten und löchen kann. Gut zu wissen, dass man hierfür das "x" braucht.

      Verzeichnisrechte ohne 'x' macht man im Normalfall eigentlich nie. Mir fällt auch auf Anhieb nichts ein, wozu man das gebrauchen könnte - aber vmtl. gibt's Spezialfälle, wo das doch irgendwie sinnvoll ist.

      Was aber z.B. problemlos möglich und in manchen Fällen auch nützlich ist, ist Verzeichniss mit 'x'-Recht aber ohne 'r'-Recht auszustatten. Damit kann man dann nicht sehen, welche Dateien in einem Verzeichnis drin sind - wenn man aber einen speziellen Dateinamen kennt, kann man die Datei dann dennoch auslesen oder in sie schreiben - mit gesetztem 'w'-Recht kann man auch Dateien anlegen und löschen.

      D.h., wenn ein Verzeichnis nur "x" aber eine Datei in diesem Verzeichnis "w", dann könnte ich die Datei bearbeiten? Das Verzeichnis selber braucht dann kein "w" mehr?
      Bräuchte ich denn nicht, um eine Datei zu bearbeiten, zusätzlich das r?, denn ich muss den Inhalt doch erst lesen können?

      PS: Wenn Du Linux haben willst, dann lade Dir VirtualBox herunter und installiere Dir irgend eine Linux-Distro (z.B. Kubuntu) in dieser virtuellen Maschine. Ist dann zwar in der VM nicht so schnell wie direkt auf dem Rechner, aber Du kannst problemlos rumspielen ohne zu große Angst haben zu müssen, etwas kaputt zu machen.

      Ja zuhause werde ich das heute Abend tun.

      Grüße

      1. Hallo,

        danke für die Ausführliche Antwort. Ich hatte gestern http://wiki.ubuntuusers.de/rechte gelesen und von daher dachte ich, dass bei ein "w" auf ein verzeichnis bedeutet, dass man Dateien/Ordner anlegen, bearbeiten und löchen kann. Gut zu wissen, dass man hierfür das "x" braucht.

        Es braucht dafür 'w' _und_ 'x'.

        Verzeichnisrechte ohne 'x' macht man im Normalfall eigentlich nie. Mir fällt auch auf Anhieb nichts ein, wozu man das gebrauchen könnte - aber vmtl. gibt's Spezialfälle, wo das doch irgendwie sinnvoll ist.

        Was aber z.B. problemlos möglich und in manchen Fällen auch nützlich ist, ist Verzeichniss mit 'x'-Recht aber ohne 'r'-Recht auszustatten. Damit kann man dann nicht sehen, welche Dateien in einem Verzeichnis drin sind - wenn man aber einen speziellen Dateinamen kennt, kann man die Datei dann dennoch auslesen oder in sie schreiben - mit gesetztem 'w'-Recht kann man auch Dateien anlegen und löschen.

        D.h., wenn ein Verzeichnis nur "x" aber eine Datei in diesem Verzeichnis "w", dann könnte ich die Datei bearbeiten?

        Ja.

        Das Verzeichnis selber braucht dann kein "w" mehr?

        Ja. Außer Du willst die Datei umbenennen/löschen, dann bräuchtest Du auf das Verzeichnis 'w'-Rechte.

        Bräuchte ich denn nicht, um eine Datei zu bearbeiten, zusätzlich das r?, denn ich muss den Inhalt doch erst lesen können?

        Auf die Datei: Ja, wenn Du wirklich _bearbeiten_ meinst. Wenn Du den alten Inhalt überschreiben können willst ohne Dich drum zu scheren brauchst Du auf die Datei kein 'r'-Recht.

        Auf das Verzeichnis brauchst Du in keinem Fall ein 'r'-Recht, wenn Du lediglich den Inhalt einer Datei bearbeiten willst.

        Viele Grüße,
        Christian

        1. Hi,
          also vielen Dank, jetzt ist mir der Unterschied schon sehr klar geworden, zwischen Verzeichnis und Datei. Kennst Du dich eigentlich auch mit I-Nodes aus?

          Ja. Außer Du willst die Datei umbenennen/löschen, dann bräuchtest Du auf das Verzeichnis 'w'-Rechte.

          Bräuchte ich denn nicht, um eine Datei zu bearbeiten, zusätzlich das r?, denn ich muss den Inhalt doch erst lesen können?

          Auf die Datei: Ja, wenn Du wirklich _bearbeiten_ meinst. Wenn Du den alten Inhalt überschreiben können willst ohne Dich drum zu scheren brauchst Du auf die Datei kein 'r'-Recht.

          Ah, ok. Wenn ich den Inhalt überschreibe, ist ein "r" nicht notwendig, ansonsten, wenn ich an den Inhalt anfüge oder mit vim öffne, brauche ich ein "r"

          Ich will noch zum Abschluss eine andere Konstellation aufführen.
          Den Ordner hat überhaupt keine Rechte. In dem Ordner ist eine Datei mit "r"
          D.h., ich könnte diese Datei kopieren und in ein anderes Ordner packen. Bzw. den Inhalt in eine andere Datei packen, für das ich mehr Rechte habe.

          Grüße

          1. Hallo,

            also vielen Dank, jetzt ist mir der Unterschied schon sehr klar geworden, zwischen Verzeichnis und Datei. Kennst Du dich eigentlich auch mit I-Nodes aus?

            Wenn Du eine konkrete Frage hast: Stelle sie.

            Ich will noch zum Abschluss eine andere Konstellation aufführen.
            Den Ordner hat überhaupt keine Rechte. In dem Ordner ist eine Datei mit "r"
            D.h., ich könnte diese Datei kopieren und in ein anderes Ordner packen. Bzw. den Inhalt in eine andere Datei packen, für das ich mehr Rechte habe.

            Naja, wenn Du für das Verzeichnis, das die Datei enthält, gar keine Rechte hast (d.h. weder 'r' noch 'w' noch 'x'), dann kommst Du auch nicht an die Datei ran (weil Dir 'x' für das Verzeichnis fehlt, siehe vorige Postings von mir). Wenn Du 'x'-Rechte auf das Verzeichnis hast (aber sonst nur 'r'-Rechte auf die Datei), dann kannst Du die Datei nur auslesen und sonst gar nichts mit tun. Wenn Du also irgendwas speichern willst, ginge das nur woanders - selbstverständlich würde das ein Kopieren der ursprünglichen Datei mit einschließen, aber an der ursprünglichen Datei könntest Du dann dennoch nichts mehr ändern.

            Viele Grüße,
            Christian

            1. Hi,

              also vielen Dank, jetzt ist mir der Unterschied schon sehr klar geworden, zwischen Verzeichnis und Datei. Kennst Du dich eigentlich auch mit I-Nodes aus?

              Wenn Du eine konkrete Frage hast: Stelle sie.

              Da kopiere ich einfach mal vom anderen Beitrag heraus:
              Zitat: "Es können max. 2^16 I-Nodes referenziert werden. Also nur 2^16 Dateien pro Dateisystem"
              D.h. das Dateisystem hat 65536 I-Nodes. (Ein I-Node hat 12 direkte Zeiger auf 1KB große Cluster, und dann einfach,zweifach, dreifach indirekte.
              Habe ich dann richtig verstanden, dass eine einfach indirekte Blockadresse im I-Node, auf ein neues I-Node im Speicherblock zeigt?
              Das würde heißen, dass die I-Nodes größer als 65536 dann dynamisch wachsend im Speicherblock liegen, anstatt im Dateisystem oder werden die auch gleich angelegt?

              Naja, wenn Du für das Verzeichnis, das die Datei enthält, gar keine Rechte hast (d.h. weder 'r' noch 'w' noch 'x'), dann kommst Du auch nicht an die Datei ran (weil Dir 'x' für das Verzeichnis fehlt, siehe vorige Postings von mir). Wenn Du 'x'-Rechte auf das Verzeichnis hast (aber sonst nur 'r'-Rechte auf die Datei), dann kannst Du die Datei nur auslesen und sonst gar nichts mit tun. Wenn Du also irgendwas speichern willst, ginge das nur woanders - selbstverständlich würde das ein Kopieren der ursprünglichen Datei mit einschließen, aber an der ursprünglichen Datei könntest Du dann dennoch nichts mehr ändern.

              Vielen Dank, geht klar. Ich habe mir auch Linux zum testen mal installiert und werde dort mal einige Konstellationen testen :-)

              Grüße

              1. Hallo,

                also vielen Dank, jetzt ist mir der Unterschied schon sehr klar geworden, zwischen Verzeichnis und Datei. Kennst Du dich eigentlich auch mit I-Nodes aus?

                Wenn Du eine konkrete Frage hast: Stelle sie.

                Da kopiere ich einfach mal vom anderen Beitrag heraus:
                Zitat: "Es können max. 2^16 I-Nodes referenziert werden. Also nur 2^16 Dateien pro Dateisystem"

                Woher hast Du das? Im Prinzip sind I-Nodes bzw. auch wo sie abgelegt werden  ein dateisystemspezifisches Konzept. In UNIX-Dateisystemen trennt man in der Regel nämlich zwischen Eintrag mit Dateinamen im Verzeichnis und Metadaten der Datei (Größe, Änderungsdatum). Man hat also 3 Schichten:

                +------------------------+           +----------------------------+
                 | Verzeichnis            |    +----->| Inode 42                   |
                 +------------------------+    |      +----------------------------+
                 | Name     I-Node-Nummer |    |      | Größe:         54 Bytes    |
                 +------------------------+    |      | Änderungsdatum: gestern    |
                 | testdatei           42-|----+      | Besitzer:   Max Mustermann |
                 | ...                 ...|           | ...                        |
                 +------------------------+           | Verwendete Blöcke:         |
                                               +------|----2                       |
                                               |   +--|---17                       |
                            +------------------+   |  |   69-------------+         |
                            |                      |  +------------------|---------+
                            |                      |                     |
                Datenblöcke im Dateisystem:        |                     |
                            |                      |                     |
                            v                      v                     v
                   +------------------+   +------------------+   +------------------+
                   | Block 2          |   | Block 17         |   | Block 69         |
                   +------------------+   +------------------+   +------------------+
                   | Anfang der Datei |   | Mitte  der Datei |   | Ende der Datei   |
                   +------------------+   +------------------+   +------------------+

                Damit ist es dann zum Beispiel möglich, dass eine Datei mehrere Einträge hat (d.h. ein Inode mehrere Dateinamen hat, die auf dieses Inode verweisen), das nennt sich dann "hard links".

                Wie viele Inodes nun möglich sind hängt stark vom Dateisystem ab - eine allgemeine Zahl kann ich Dir nicht nennen. Manchmal kann man die Maximalanzahl auch festlegen, wenn man das Dateisystem anlegt. Die Maximalzahl an Inodes gibt (grob) die Maximalzahl an inhaltlich unterschiedlichen Dateien an, die es im Dateisystem geben kann.

                Wenn Du das dagegen mit dem FAT-Dateisystem (DOS, Windows) vergleichst, dann sieht das dort etwas anders aus: Dort gibt es sowas wie "hard links" nicht, jede Datei darf nur einmal referenziert werden. Alle Metadaten zur Datei werden bereits im Verzeichniseintrag mitgespeichert und dort werden dann auch die verwendeten Blöcke der Datei referenziert. (Genaugenommen wird bei FAT der erste Block referenziert und alle weiteren Blöcke sind dann über eine Art "Kette", die woanders abgelegt wird, erreichbar.)

                Wenn Du nun aber ein FAT-Dateisystem unter Linux einbindest, dann emuliert der FAT-Dateisystemtreiber unter Linux das INode-Konzept, da die Dateisystemschicht im Linux-Kernel INodes erwartet. Dies ist nicht nur bei FAT so, es gibt auch noch viele andere Dateisysteme, die das Konzept von Inodes nicht kennen, sondern Dateien irgendwie anders ablegen.

                Ich hoffe, ich konnte das Konzept von Inodes etwas klarer machen.

                Viele Grüße,
                Christian

                1. Hi,

                  Wenn Du das dagegen mit dem FAT-Dateisystem (DOS, Windows) vergleichst, dann sieht das dort etwas anders aus: Dort gibt es sowas wie "hard links" nicht, jede Datei darf nur einmal referenziert werden.

                  so die Theorie. Tatsächlich ist es auch bei FAT möglich, dass mehrere Verzeichniseinträge auf denselben Cluster (so der FAT-übliche Begriff) verweisen. Das Prinzip der Hardlinks lässt sich dadurch nachbilden.
                  Allerdings fehlt ein Zähler, der angibt, von wievielen Verzeichniseinträgen ein Cluster referenziert wird. Deswegen ist das Löschen solcher mehrfach referenzierten Dateien problematisch - sie würde schon beim ersten Versuch tatsächlich gelöscht, und weitere noch existierende Verzeichniseinträge würden ins Leere zeigen.
                  Deswegen gibt es auch keine Möglichkeit, solche Mehrfachreferenzen anzulegen (außer mit einem Disk-Editor von Hand), und wenn welche existieren, wird das bei einer Überprüfung des Datenträgers als Dateisystemfehler gemeldet.
                  Auf Datenträgern, wo keine Schreibzugriffe vorgesehen sind, wurde das aber früher ab und zu gemacht. Beispielsweise auf Installationsdisketten, die sowieso schreibgeschützt waren.

                  Alle Metadaten zur Datei werden bereits im Verzeichniseintrag mitgespeichert

                  Richtig, und das birgt die zusätzliche Problematik, dass Mehrfachverlinkungen -wenn man sie mit Gewalt erzeugt- widersprüchlich sein können, z.B. unterschiedliche Dateigrößen anzeigen.

                  (Genaugenommen wird bei FAT der erste Block referenziert und alle weiteren Blöcke sind dann über eine Art "Kette", die woanders abgelegt wird, erreichbar.)

                  Genau, diese Verkettung wird in der File Allocation Table oder kurz FAT abgelegt, die dem Dateisystem seinen Namen gab.

                  Wenn Du nun aber ein FAT-Dateisystem unter Linux einbindest, dann emuliert der FAT-Dateisystemtreiber unter Linux das INode-Konzept, da die Dateisystemschicht im Linux-Kernel INodes erwartet.

                  Das ist ein interessantes Detail, danke.

                  Dies ist nicht nur bei FAT so, es gibt auch noch viele andere Dateisysteme, die das Konzept von Inodes nicht kennen, sondern Dateien irgendwie anders ablegen.

                  Zum Beispiel ISO9660, das ähnlich aufgebaut ist wie FAT, nur eben ohne FAT - da wird vorausgesetzt, dass eine Datei immer zusammenhängend in aufeinanderfolgenden Sektoren gespeichert ist. Sowas wie Fragmentierung gibt es nicht.

                  Ciao,
                   Martin

                  --
                  F: Was macht ein Offizier, der in der Nase bohrt?
                  A: Er holt das Letzte aus sich heraus.
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                  1. Hi,

                    Zum Beispiel ISO9660, das ähnlich aufgebaut ist wie FAT, nur eben ohne FAT - da wird vorausgesetzt, dass eine Datei immer zusammenhängend in aufeinanderfolgenden Sektoren gespeichert ist. Sowas wie Fragmentierung gibt es nicht.

                    Wäre das die Blockreservierung?

                    Grüße

                    1. Hallo,

                      Zum Beispiel ISO9660, das ähnlich aufgebaut ist wie FAT, nur eben ohne FAT - da wird vorausgesetzt, dass eine Datei immer zusammenhängend in aufeinanderfolgenden Sektoren gespeichert ist. Sowas wie Fragmentierung gibt es nicht.
                      Wäre das die Blockreservierung?

                      nicht wirklich - ISO9660 ist von Anfang an als Read-Only-Dateisystem konzipiert. Es wird normalerweise aus einem gegebenen Dateibestand einmal erstellt und dann nie wieder verändert. Deswegen kann es auch zum Zeitpunkt der Erstellung in schöner Ordnung und unfragmentiert angelegt werden, und die Ordnung bleibt erhalten. Der Verzeichniseintrag enthält dann neben Metadaten wie Zeitstempel oder Dateiattributen nur noch die Dateigröße und den Startsektor. Beim Lesen der Datei kann der Treiber sich dann darauf verlassen, dass alle Folgesektoren linear in einer Reihe abgelegt sind.

                      Blockreservierung ist ja eher ein Feature von Dateisystemen, die Schreibzugriffe unterstützen. Da wird sofort beim Anlagen einer Datei entweder der benötigte Platz am Stück auf dem Datenträger belegt (wenn die Größe der entstehenden Datei bekannt ist, etwa beim einfachen Kopieren), oder es wird einfach auf Verdacht eine Größe geschätzt, und ein entsprechend großer Block reserviert.
                      Wenn die Datei nach dem Bearbeiten geschlossen wird und die tatsächliche Größe ist kleiner als geschätzt, wird der Block halt nachträglich verkleinert und der Rest wieder freigegeben. Wird die Datei dagegen größer als der Treiber im Voraus angenommen hat, müssen zusätzliche Blöcke angelegt werden.

                      Ciao,
                       Martin

                      --
                      F: Was ist schneller: Das Licht oder der Schall?
                      A: Offensichtlich der Schall. Wenn man den Fernseher einschaltet, kommt immer erst der Ton, und dann erst das Bild.
                      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                      1. Hi Martin,

                        »

                        nicht wirklich - ISO9660 ist von Anfang an als Read-Only-Dateisystem konzipiert. Es wird normalerweise aus einem gegebenen Dateibestand einmal erstellt und dann nie wieder verändert. Deswegen kann es auch zum Zeitpunkt der Erstellung in schöner Ordnung und unfragmentiert angelegt werden, und die Ordnung bleibt erhalten. Der Verzeichniseintrag enthält dann neben Metadaten wie Zeitstempel oder Dateiattributen nur noch die Dateigröße und den Startsektor. Beim Lesen der Datei kann der Treiber sich dann darauf verlassen, dass alle Folgesektoren linear in einer Reihe abgelegt sind.

                        verstehe, vielen Dank für die Erklärung :-)
                        Dann wäre dieser Thread eigentlich abgeschlossen, wegen dem Überlauf mache ich mir dann nochmals Gedanken. Nur das hängt noch einwenig im Kopf herum, ist aber nicht so wild.

                        Viele Grüße und noch einen schönen sonnigen Donnerstagabend

                2. Hi,

                  Woher hast Du das? Im Prinzip sind I-Nodes bzw. auch wo sie abgelegt werden  ein dateisystemspezifisches Konzept. In UNIX-Dateisystemen trennt man in der Regel nämlich zwischen Eintrag mit Dateinamen im Verzeichnis und Metadaten der Datei (Größe, Änderungsdatum). Man hat also 3 Schichten:

                  Wir haben gerade mal 5-6 kleine Folien zu I-Nodes im Script. Gleich im zweiten steht, dass die Anzahl der I-Nodes durch 2^16 begrenzt sei, deshalb gäbe es dann die einfach, zweifach und dreifach indirekten Zeiger.
                  D.h., der bei einem einfach indirekten Zeiger, zeigt das I-Node dann auf einen Block, in der dann bei 1KB Blockgröße und 16bit (4B) weitere 256 Blocks referenziert werden können. (So habe ich das zumindest gedeutet)

                  +------------------------+           +----------------------------+
                  | Verzeichnis            |    +----->| Inode 42                   |
                  +------------------------+    |      +----------------------------+
                  | Name     I-Node-Nummer |    |      | Größe:         54 Bytes    |
                  +------------------------+    |      | Änderungsdatum: gestern    |
                  | testdatei           42-|----+      | Besitzer:   Max Mustermann |
                  | ...                 ...|           | ...                        |
                  +------------------------+           | Verwendete Blöcke:         |
                                                 +------|----2                       |
                                                 |   +--|---17                       |
                              +------------------+   |  |   69-------------+         |
                              |                      |  +------------------|---------+
                              |                      |                     |
                  Datenblöcke im Dateisystem:        |                     |
                              |                      |                     |
                              v                      v                     v
                     +------------------+   +------------------+   +------------------+
                     | Block 2          |   | Block 17         |   | Block 69         |
                     +------------------+   +------------------+   +------------------+
                     | Anfang der Datei |   | Mitte  der Datei |   | Ende der Datei   |
                     +------------------+   +------------------+   +------------------+

                  Damit ist es dann zum Beispiel möglich, dass eine Datei mehrere Einträge hat (d.h. ein Inode mehrere Dateinamen hat, die auf dieses Inode verweisen), das nennt sich dann "hard links".

                  Danleschön. Das ist voll lieb, dass man das noch so schön grafisch zur Verdeutlichung aufgezeigt hat. Wurde mir auf jedenfall viel klarer. Wenn ich an die Beschränkung von 2^16 denke (so wie es bei uns im Script steht), dann könnte das Dateisystem ja nur 65536 Dateien verwalten, was überhaupt kein Sinn macht. Ich frage die nächsten Wochen, sobald ich den Professor noch sehe diesbezüglich nochmals nach, was er damit gemeint hat. Komisch ist es auf jedenfall.

                  Wie viele Inodes nun möglich sind hängt stark vom Dateisystem ab - eine allgemeine Zahl kann ich Dir nicht nennen. Manchmal kann man die Maximalanzahl auch festlegen, wenn man das Dateisystem anlegt. Die Maximalzahl an Inodes gibt (grob) die Maximalzahl an inhaltlich unterschiedlichen Dateien an, die es im Dateisystem geben kann.

                  Ich hätte vermutet, dass die Anzahl evtl. an der Adressierung (Adressleitungen zur Festplatte beschränkt sei). 16, 32, 64 bit. (Genau so viele Dateien kann es dann verarbeiten)

                  Wenn Du nun aber ein FAT-Dateisystem unter Linux einbindest, dann emuliert der FAT-Dateisystemtreiber unter Linux das INode-Konzept, da die Dateisystemschicht im Linux-Kernel INodes erwartet. Dies ist nicht nur bei FAT so, es gibt auch noch viele andere Dateisysteme, die das Konzept von Inodes nicht kennen, sondern Dateien irgendwie anders ablegen.

                  Das hört sich interessant an.

                  Ich hoffe, ich konnte das Konzept von Inodes etwas klarer machen.

                  Ja auf jedenfall. Vielen Dank. Das hat mir auf jedenfall sehr geholfen, dankeschön.
                  Die einzige Kleinigkeit in diesem Thread, was ich nicht verstanden hatte liegt noch in diesem Beitrag: http://forum.de.selfhtml.org/?t=198804&m=1335966
                  Wobei das aber sicherlich nicht so wichtig ist. Vielleicht kann der Martin mir evtl. auf die Sprünge noch helfen mit dem Überlauf?

                  Grüße

                  1. Hallo,

                    Woher hast Du das? Im Prinzip sind I-Nodes bzw. auch wo sie abgelegt werden  ein dateisystemspezifisches Konzept. In UNIX-Dateisystemen trennt man in der Regel nämlich zwischen Eintrag mit Dateinamen im Verzeichnis und Metadaten der Datei (Größe, Änderungsdatum). Man hat also 3 Schichten:

                    Wir haben gerade mal 5-6 kleine Folien zu I-Nodes im Script. Gleich im zweiten steht, dass die Anzahl der I-Nodes durch 2^16 begrenzt sei, deshalb gäbe es dann die einfach, zweifach und dreifach indirekten Zeiger.

                    Ähm, mit den indirekten Zeigern ist etwas anderes gemeint. In meinem Diagramm habe ich die Blöcke für die Datei einfach unter 'verwendete Blöcke' abgetan und bin nicht näher auf die Details eingegangen. Das Problem ist aber, dass wenn man z.B. eine Blockgröße von 4 KiB annimmt (was typisch ist) für eine Datei mit 4 MiB ganze 1024 Blöcke zum Speichern der enthaltenen Daten braucht. Jetzt müssen im Dateisystem irgendwie 1024 Blocknummern abgelegt werden. Verschiedene Dateisysteme verwenden verschiedene Strategien dafür.

                    Im konkreten Fall des ext2-Dateisystems (gilt *nicht* allgemein für jedes Dateisystem unter Linux!) gibt es folgende Strategie: Pro Inode-Eintrag ist nach den ganzen Metadaten noch Platz für 15 Referenzen auf Blöcke. Nun würde man mit 15 Blöcken pro Datei auf magere 60 KiB kommen - das wäre etwas wenig. ;-) Daher wird folgendes gemacht: Die ersten 12 Einträge zeigen auf die ersten 12 Blöcke der Datei. Der 13. Eintrag zeigt auf einen Block (der dann nicht mehr für Daten zur Verfügung steht), der selbst wieder Zeiger auf die nächsten Blöcke (ab dem 13. Block der Datei) zeigt. Aber es passen ja nur soundsoviele Zeiger in einen Block (typischerweise 1024 Stück), d.h. dann wäre nach knapp über 4 MiB für die maximale Dateigröße Schluss - auch noch viel zu wenig. Also zeigt der 14. Eintrag in der Inode auf einen Block, der Zeiger auf Blöcke enthält, die selbst zeiger auf Blöcke mit dem Inhalt enthalten. Und beim 15. gibt's dann 3 Indirektionsschichten. Um das mal aufzumalen:

                    (xxx == irgend eine Zahl, die den Block angibt, ich bin zu faul mir jetzt
                      so extrem viele zufällige Zahlen auszudenken)
                     (aaa, bbb, ccc == irgend eine Zahl, die einen Block angibt, der Zeiger
                      auf weitere Blöcke enthält)

                    (bitte Browserfenster groß machen, damit man die Zeichnung erkennen
                      kann)

                    +------------------------+
                     | Inode                  |
                     +------------------------+
                     | Metadaten              |
                     | (Dateigröße, Rechte,   |
                     | Erstellungsdatum, ...) |
                     +------------------------+
                     | Blockreferenzen        | ____
                     |  1. xxx                |     \
                     |  2. xxx                |      |
                     |  3. xxx                |      |
                     |  4. xxx                |      |
                     |  5. xxx                |      |
                     |  6. xxx                |      \____ Diese verweisen direkt auf die
                     |  7. xxx                |      /     ersten 12 Blöcke mit dem Inhalt
                     |  8. xxx                |      |     der Datei.
                     |  9. xxx                |      |
                     | 10. xxx                |      |
                     | 11. xxx                |      |
                     | 12. xxx                |_____/         +--------------------+
                     | 13. aaa     -----------|-------------->| Block mit Zeigern* |
                     | 14. bbb     -----------|----------+    +--------------------+__
                     | 15. ccc     -----------|--+       |    |    xxx             |  \
                     +------------------------+  |       |    |    xxx             |   |_  Diese verweisen auf die nächsten
                                                 |       |    |    ...             |   |   Inhaltsblöcke der Datei.
                                      +----------+       |    |    xxx             |__/
                                      |                  |    +--------------------+
                                      v                  v
                         +--------------------+       +--------------------+
                         | Block mit Zeigern* |       | Block mit Zeigern* |
                         +--------------------+       +--------------------+
                         | bbb                |       | aaa                |
                         | bbb                |       | aaa                |
                         | ...                |       | ...                |
                      +--|-bbb                |       | aaa ---------------|-----+
                      |  +--------------------+       +--------------------+     |
                      |                                                          |
                      |       +--------------------+                             v
                      +------>| Block mit Zeigern* |                   +--------------------+
                              +--------------------+                   | Block mit Zeigern* |
                              | aaa                |                   +--------------------+__
                              | aaa                |                   | xxx                |  \
                              | ...                |                   | xxx                |   |_____
                              | aaa----------------|------+            | ...                |   |     |
                              +--------------------+      |            | xxx                |__/      |
                                                          |            +--------------------+         |
                                                          v                                           |
                                           +--------------------+                          Diese verweisen auf
                                           | Block mit Zeigern* |                        die nächsten Inhaltsblöcke
                                           +--------------------+__                            der Datei.
                                           | xxx                |  \
                                           | xxx                |   |___ Diese verweisen auf die nächsten
                                           | ...                |   |    Inhaltsblöcke der Datei.
                                           | xxx                |__/
                                           +--------------------+

                    * Diese Blöcke stehen natürlich nicht mehr für Dateiinhalt zur Verfügung
                       und Nehmen daher Platz im Dateisystem weg.

                    Wohlgemerkt: Dies gilt *nur* für das ext2-Dateisystem (und vermutlich auch, wg. Kompabilität damit, ext3 und ext4) - andere Dateisysteme können das vollkommen anders implementieren, es ist kein allgemeines Prinzip von Linux-Dateisystemen.

                    Woher Deine Zahl mit 2^16 Inodes kommt, ist mir aber weiterhin schleierhaft (und die Indirektion hat ja wie Du gesehen hast nichts mit der Zahl der Inodes zu tun sondern nur etwas wie Inodes Blöcke referenzieren) - mein ext4-Dateisystem auf einer 60 GiB-Partition hat zum Beispiel maximal 4833280 Inodes zur Verfügung (und damit wäre dies das theoretische Maximum an Dateien auf dieser Partition).

                    Wenn ich an die Beschränkung von 2^16 denke (so wie es bei uns im Script steht), dann könnte das Dateisystem ja nur 65536 Dateien verwalten, was überhaupt kein Sinn macht.

                    Ja, eben. Ich verwende von meinen 4 Millionen Inodes ja schon über 800000, d.h. wenn mein Limit 65536 wäre, dann wäre ich schon längst aufgeschmissen. ;-)

                    Wie viele Inodes nun möglich sind hängt stark vom Dateisystem ab - eine allgemeine Zahl kann ich Dir nicht nennen. Manchmal kann man die Maximalanzahl auch festlegen, wenn man das Dateisystem anlegt. Die Maximalzahl an Inodes gibt (grob) die Maximalzahl an inhaltlich unterschiedlichen Dateien an, die es im Dateisystem geben kann.

                    Ich hätte vermutet, dass die Anzahl evtl. an der Adressierung (Adressleitungen zur Festplatte beschränkt sei). 16, 32, 64 bit. (Genau so viele Dateien kann es dann verarbeiten)

                    Die Maximalzahl an Inodes ist natürlich schon irgendwie durch die Größe des Inode-Zählers in einem Verzeichniseintrag begrenzt (d.h. wie viel bit der hat), aber ein Dateisystem hat evtl. noch zusätzliche, andere Limits auf die maximale Inode-Zahl außer der reinen Größe dieses Zählers.

                    Vergiss aber bitte mal die Adressleitungen der Festplatte an dieser Stelle: Wie physikalische Festplattensektoren adressiert werden gibt Dir nur eine Grenze für die maximal ansprechbare Festplattenkapazität (hardwaremäßig!), was Du an Daten und somit auch was für ein Dateisystem Du drauftust, ist da völlig egal.

                    Viele Grüße,
                    Christian