Was ist das Konzept zum Erstellen einer Datei mit null Bytes in Linux?

Wenn ich folgendes mache:

touch /tmp/test

und dann durchführen

ls -la /tmp/

Ich konnte die testDatei mit 0 Bytes im Verzeichnis sehen.

Aber wie geht das Betriebssystem mit einem Konzept von um? 0 Bytes . Wenn ich es als Laie formuliere:

0 Bytes ist überhaupt kein Speicher, daher wird nichts erstellt.

Erstellen einer Datei, muss oder sollte zumindest bestimmte Speicher erfordern, oder?

Eine Datei besteht (ungefähr) aus drei verschiedenen Dingen:

• Ein "Inode", eine Metadatenstruktur, die den Eigentümer der Datei, die Berechtigungen und eine Liste der Blöcke auf der Festplatte protokolliert, die die Daten tatsächlich enthalten.
• Ein oder mehrere Verzeichniseinträge (die Dateinamen), die auf diesen Inode verweisen
• Die eigentlichen Datenblöcke selbst

Wenn Sie eine leere Datei erstellen, erstellen Sie nur den Inode und einen Verzeichniseintrag, der auf diesen Inode verweist. Gleiches gilt für Dateien mit geringer Dichte ( dd if=/dev/null of=sparse_file bs=10M seek=1).

Wenn Sie Hardlinks zu einer vorhandenen Datei erstellen, erstellen Sie lediglich zusätzliche Verzeichniseinträge, die auf denselben Inode verweisen.

Ich habe die Dinge hier vereinfacht, aber Sie haben die Idee.

touchein schaffen wird Inode und ls -ioder statzeigt Informationen über den Inode:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

Beachten Sie, dass test0 Blöcke verwendet werden. Zum Speichern der angezeigten Daten verwendet der Inode einige Bytes. Diese Bytes werden in der Inode-Tabelle gespeichert. Auf der Seite ext2 finden Sie ein Beispiel für eine Inode-Struktur .

ls(oder auch der stat(2)Systemaufruf) gibt Auskunft über die Größe des Inhalts der Datei. Wie viel Speicherplatz das Dateisystem für die Buchhaltung benötigt, gehört nicht dazu, und als Implementierungsdetail sollten sich Programme im Allgemeinen nicht darum kümmern oder auch nur darüber Bescheid wissen. Das Sichtbarmachen der Implementierungsdetails würde die Dateisystemabstraktion weniger nützlich machen.

Die Datei selbst belegt keinen Speicherplatz, das Dateisystem jedoch speichert Dateinamen, Speicherort, Zugriffsrechte und dergleichen.

Einfache Antwort: Weil es so definiert ist.

Längere Antwort: Es ist so definiert, weil einige Operationen konzeptionell einfacher sind:

• Wenn eine Datei 20 Buchstaben "A" enthält und Sie alle "A" entfernen, wird die Datei 20 Byte kürzer. Dieselbe Operation für eine Datei, die nur aus "AAAAAAAAAAAAAAAAAAAA" bestand, musste den Sonderfall einer verschwindenden Datei behandeln.
• In der Praxis müsste das Löschen der letzten Zeile einer Textdatei in einem speziellen Fall erfolgen.
• Texteditoren, die regelmäßig eine Sicherungskopie erstellen, benötigen Sonderfallcode, um die Situation zu bewältigen, in der der Benutzer möglicherweise die letzte Zeile löscht, zum Mittagessen geht und dann zurückkehrt und eine weitere Zeile hinzufügt. Weitere Komplikationen ergeben sich, wenn andere Benutzer in der Zwischenzeit eine Datei mit diesem Namen erstellt haben.

Sie können noch mehr tun: * Fehlerprotokolldateien werden in der Regel leer erstellt und nur dann gefüllt, wenn ein Fehler auftritt. * Um herauszufinden, wie viele Fehler aufgetreten sind, zählen Sie die Anzahl der Zeilen in den Protokolldateien. Wenn die Protokolldatei leer ist, ist die Anzahl der Fehler Null, was durchaus Sinn macht. * Manchmal sehen Sie Dateien, in denen der gesamte relevante Text im Dateinamen enthalten ist, z . B. oder .this-is-the-logging-directory . Auf diese Weise wird verhindert, dass überlastete Administratoren nach der Installation leere Verzeichnisse löschen. Außerdem wird verhindert, dass ein Programm oder ein Benutzer versehentlich eine Datei erstellt, in der das Programm später ein Verzeichnis sehen möchte. Das gitProgramm (und andere) ignorieren leere Verzeichnisse. Wenn ein Projekt / Administrator / Benutzer einen Datensatz haben möchte, in dem das Verzeichnis vorhanden ist, obwohl es (noch) keinen nützlichen Inhalt hat, wird möglicherweise eine leere Datei mit dem Namen angezeigtemptyempty.directory

Keine Operationen werden komplizierter:

• Verketten von Dateien: Dies ist nur ein No-Op mit einer leeren Datei.
• Suchen nach einer Zeichenfolge in einer Datei: Dies wird durch den Standardfall "Wenn die Datei kürzer als der Suchbegriff ist, kann sie den Suchbegriff nicht enthalten" abgedeckt.
• Lesen aus der Datei: Programme müssen damit fertig werden, das Ende der Datei zu erreichen, bevor sie das bekommen, was sie erwartet haben. Wiederum erfordert der Fall einer Datei mit der Länge Null keine zusätzlichen Überlegungen für den Programmierer: Er wird nur das Ende der Datei erreichen -Datei von Anfang an.

Bei Dateien kommt der Aspekt "Es ist eine Datei irgendwo aufgezeichnet" (Inode und / oder Dateiname) zu den obigen Überlegungen hinzu, aber Dateisysteme würden dies nicht tun, wenn leere Dateien unbrauchbar wären.

Im Allgemeinen gelten alle oben genannten Gründe mit Ausnahme derjenigen, die sich auf Dateinamen beziehen, für Sequenzen. Vor allem bei Strings, bei denen es sich um Sequenzen von Zeichen handelt: Strings mit einer Länge von Null sind in Programmen alltäglich. Zeichenfolgen sind auf Benutzerebene normalerweise nicht zulässig, wenn sie keinen Sinn ergeben: Ein Dateiname ist eine Zeichenfolge, und die meisten Dateisysteme lassen keine leere Zeichenfolge als Dateinamen zu. Intern kann das Programm beim Erstellen von Dateinamen aus Fragmenten eine leere Zeichenfolge als eines der Fragmente haben.

Mit der einfachsten Analogie:

Vergleichen wir eine Akte beispielsweise mit einem Glas Wasser.

'touch / tmp / test' ähnelt sehr der Herstellung eines leeren Glases, in dem sich kein Wasser befindet. Das Glas ist leer, also ist es gleich Null. Aber das Glas existiert.

In der Dateisystemsprache sind das Glas die Metadaten, während der Inhalt des Glases die Daten sind. Die Metadaten enthalten alle möglichen Dinge, wie in den vorherigen Beiträgen erwähnt.

Dateien mit der Größe Null können nützlich sein. Ein Beispiel ist die Verwendung als Breadcrumb, wobei die bloße Existenz verwendet werden kann, um einen Zustand anzuzeigen (dh, wenn die Datei vorhanden ist: dann tue etwas, wenn nicht: ignoriere).

Stellen Sie sich das so vor: Angenommen, ein Programm verfolgt SQL-Abfragen, die an Ihren Server gesendet wurden. Das Programm möchte anzeigen, dass Anforderungen in einer Nur-Text-Datei protokolliert werden, es wurden jedoch noch keine Anforderungen protokolliert. Wie soll das aussehen? Ich würde argumentieren, dass es eine Datei mit der Größe Null sein sollte /var/log/acme-sql-server/queries.log. Auf diese Weise können Sie herausfinden, wann die Protokollierung gestartet wurde (Erstellungszeit der Datei), wann sie zuletzt aktualisiert wurde (dh wann sie erstellt wurde), wie viele Abfragen aufgezeichnet wurden (Anzahl der Zeilenumbrüche in Datei = 0) und wer die Protokollierung durchführt (Acme SQL Server). In solchen Fällen ist es nützlich, das Konzept einer leeren Datei zu haben, die dennoch an einem bestimmten Ort vorhanden ist.