Provided by: manpages-de-dev_4.21.0-2_all bug

BEZEICHNUNG

       read - aus einem Dateideskriptor lesen

BIBLIOTHEK

       Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT

       #include <unistd.h>

       ssize_t read(int dd, void Puffer[.Anzahl], size_t Anzahl);

BESCHREIBUNG

       read()  versucht,  bis  zu  Anzahl  Byte  aus  dem  Dateideskriptor  dd  in den bei Puffer
       beginnenden Puffer zu lesen.

       Bei Dateien, die das Durchsuchen unterstützen,  beginnt  der  Lesevorgang  am  Offset  der
       Datei,  wobei der Datei-Offset durch die Anzahl der gelesenen Bytes erhöht wird. Falls der
       Datei-Offset am Ende oder hinter dem Ende der Datei liegt, werden keine Bytes gelesen  und
       read() gibt Null zurück.

       Falls  Anzahl  Null  ist,  kann  read()  eventuell  die  nachfolgend  beschriebenen Fehler
       erkennen. Ohne jegliche Fehlermeldungen, oder wenn read() nicht auf Fehler prüft, gibt ein
       Aufruf von read() und wenn Anzahl 0 ist, Null zurück und hat keine weiteren Auswirkungen.

       Laut  POSIX.1  hängt  das  Ergebnis  von  der  Implementierung ab, falls Anzahl größer als
       SSIZE_MAX ist; siehe ANMERKUNGEN für die Obergrenze unter Linux.

RÜCKGABEWERT

       Bei Erfolg wird die Anzahl der gelesenen Bytes zurückgegeben (null bedeutet Dateiende) und
       die Position in der Datei wird um diese Anzahl erhöht. Es ist kein Fehler, wenn diese Zahl
       kleiner ist als die Zahl der angeforderten Bytes; das kann geschehen, wenn gerade wirklich
       weniger Bytes verfügbar sind (vielleicht ist das Dateiende nah oder es wird aus einer Pipe
       oder von einem Terminal gelesen) oder weil read() durch  ein  Signal  unterbrochen  wurde.
       Siehe auch ANMERKUNGEN.

       Im  Fehlerfall  wird -1 zurückgegeben und errno wird gesetzt, um den Fehler anzuzeigen. In
       diesem Fall ist nicht festgelegt, ob die Position in der Datei  (wenn  es  überhaupt  eine
       gibt) geändert wird.

FEHLER

       EAGAIN Der  Dateideskriptor dd bezieht sich auf eine Datei, die kein Socket ist, und wurde
              als nicht blockierend (O_NONBLOCK) markiert und das Lesen würde  blockieren.  Siehe
              open(2) für weitere Details über den Schalter O_NONBLOCK.

       EAGAIN oder EWOULDBLOCK
              Der  Dateideskriptor dd bezieht sich auf ein Socket und wurde als nicht blockierend
              (O_NONBLOCK) markiert und das  Lesen  würde  blockieren.  POSIX.1-2001  erlaubt  in
              diesem Fall, dass eine der beiden Fehlermeldungen zurückgeliefert wird und verlangt
              nicht, dass beide Konstanten  den  gleichen  Wert  haben.  Daher  sollten  portable
              Anwendungen auf beide Möglichkeiten prüfen.

       EBADF  dd ist kein gültiger Dateideskriptor oder ist nicht zum Lesen geöffnet.

       EFAULT Puffer liegt außerhalb Ihres adressierbaren Adressraums.

       EINTR  Der  Aufruf  wurde durch ein Signal unterbrochen, bevor Daten gelesen wurden; siehe
              signal(7).

       EINVAL dd ist einem Objekt zugeordnet, aus dem nicht gelesen werden kann; oder  die  Datei
              wurde  mit  dem  Schalter  O_DIRECT  geöffnet und entweder die in Puffer angegebene
              Adresse, der in Anzahl angegebene Wert oder der Datei-Offset ist nicht entsprechend
              ausgerichtet.

       EINVAL dd  wurde  über  einen  Aufruf  von  timerfd_create(2)  erstellt  und  der  falsche
              Größenpuffer  wurde  an  read()  übergeben;  siehe  timerfd_create(2)  für  weitere
              Informationen.

       EIO    E/A-Fehler.   Dies   wird  zum  Beispiel  passieren,  wenn  der  Prozess  zu  einer
              Hintergrund-Prozessgruppe gehört und versucht, von seinem  steuernden  Terminal  zu
              lesen  und  er  entweder  SIGTTIN  ignoriert  oder  sperrt oder seine Prozessgruppe
              verwaist ist. Es kann auch durch einen Low-Level-E/A-Fehler während des Lesens  von
              einer  Platte  oder einem Band gesetzt werden. Ein weitere mögliche Ursache von EIO
              bei Netzwerkdateisystemen sind empfohlene  Sperren,  die  aus  dem  Dateideskriptor
              herausgenommen  wurden,  und  diese  Sperre  dann  verloren gegangen ist. Siehe den
              Abschnitt Verlorene Sperren von fcntl(2) für weitere Details.

       EISDIR dd referenziert ein Verzeichnis.

       Abhängig von dem mit dd verbundenen Objekt können andere Fehler auftreten.

STANDARDS

       SVr4, 4.3BSD, POSIX.1-2001.

ANMERKUNGEN

       Die Typen size_t und ssize_t  sind,  respektive,  vorzeichenlose  und  vorzeichenbehaftete
       Ganzzahldatentypen, wie durch POSIX.1 spezifiziert.

       Unter  Linux wird read() (und ähnliche Systemaufrufe) höchstens 0x7ffff000 (2.147.479.552)
       Byte übertragen und die Anzahl der  tatsächlich  übertragenen  Bytes  zurückliefern.  Dies
       trifft sowohl auf 32- als auch auf 64-Bit-Systemen zu.

       Auf  NFS-Dateisystemen aktualisiert das Lesen kleiner Datenmengen den Zeitstempel nur beim
       ersten Mal, nachfolgende Anrufe können das nicht tun. Dies wird  durch  das  clientseitige
       »attribute  caching«  (Zwischenspeichern der Attribute) verursacht, weil die meisten, wenn
       nicht alle NFS-Clients die Aktualisierung  von  st_atime  (die  letzte  Zugriffszeit)  dem
       Server  überlassen  und Leseaktionen auf Clientseite, die aus seinem Cache bedient werden,
       st_atime nicht aktualisieren, weil nicht vom Server gelesen wird. UNIX-Semantik kann durch
       Deaktivieren  des  clientseitigen  attribute cachings erhalten werden, aber in den meisten
       Fällen wird dadurch die Serverlast deutlich erhöht und die Leistung verringert.

FEHLER

       Laut POSIX.1-2008/SUSv4 Abschnitt  XSI  2.9.7  (»Thread  Interactions  with  Regular  File
       Operations«):

           Alle  der  folgenden Funktionen müssen im Hinblick aufeinander atomar bezüglich der in
           POSIX.1-2008  angegebenen  Effekte  sein,  wenn  sie  auf   regulären   Dateien   oder
           symbolischen Links arbeiten: …

       Unter den im Folgenden aufgeführten APIs sind read() und readv(2). Und unter den Effekten,
       die über Threads (und Prozesse) hinweg atomar sein sollten,  ist  die  Aktualisierung  des
       Dateiversatzes. Unter Linux vor Version 3.14 war das allerdings nicht der Fall: Falls zwei
       Prozesse, die eine offene Dateideskription gemeinsam nutzten (siehe open(2))  gleichzeitig
       einen  read()  (oder  readv(2))  durchführten,  waren die E/A-Aktionen im Hinblick auf die
       Aktualisierung des  Dateiversatzes  nicht  atomar.  Das  Ergebnis  war,  dass  beim  Lesen
       erhaltene  Datenblöcken  in den zwei Prozessen sich (inkorrekterweise) überlappten. Dieses
       Problem wurde in Linux 3.14 behoben.

SIEHE AUCH

       close(2),  fcntl(2),  ioctl(2),  lseek(2),  open(2),  pread(2),  readdir(2),  readlink(2),
       readv(2), select(2), write(2), fread(3)

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Michael Haardt <michael@moria.de>,
       Martin     Eberhard     Schauer     <Martin.E.Schauer@gmx.de>,      Mario      Blättermann
       <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung  ist  Freie  Dokumentation;  lesen  Sie  die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der  Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.