Provided by: manpages-de-dev_4.13-4_all bug

BEZEICHNUNG
       read - aus einem Dateideskriptor lesen


ÜBERSICHT
       #include <unistd.h>

       ssize_t read(int dd, void *Puffer, 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  entsprechend gesetzt. 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.


KONFORM ZU
       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)


KOLOPHON
       Diese Seite ist Teil der Veröffentlichung  5.10  des  Projekts  Linux-man-pages.  Eine  Beschreibung  des
       Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
       sich unter https://www.kernel.org/doc/man-pages/.


Ü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 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.

Linux                                            2. Februar 2018                                         READ(2)