read(2) System Calls Manual read(2)

read - lees van een bestandbeschrijving

Standard C bibliotheek (libc, -lc)

#include <unistd.h>
ssize_t read(int fd, void buf[.tel], size_t tel);

read() probeert tot aan tel bytes van bestandsbeschrijving bes_ind in te lezen naar de buffer buf.

In bestanden die zoeken ondersteunen begint de lees-operatie bij de bestandspositie, en wordt de bestandspositie verhoogd met het aantal gelezen bytes. Als de bestandspositie op of voorbij het einde van het bestand staat, dan worden geen bytes gelezen en geeft read() nul terug.

Als tel nul is, kan read() fouten zoals hieronder beschreven detecteren. In afwezigheid van enige fout, of als read() niet op fouten controleert, zal een read() met een tel gelijk 0 een 0 teruggeven en heeft verder geen andere effecten.

Volgens POSIX.1 als tel groter is dan SSIZE_MAX dan is het resultaat implementatie afhankelijk; zie OPMERKINGEN voor de boven grens op Linux.

Bij success wordt het aantal gelezen bytes teruggegeven (nul betekend einde van het bestand); de positie in het bestand wordt met dit aantal vooruitgezet. Het is niet fout als dat aantal kleiner is dan het gevraagde aantal bytes, dat kan bijvoorbeeld gebeuren als er minder bytes voorhanden zijn op dat ogenblik (wellicht omdat we dicht bij eind-van-bestand zijn, omdat we van een pijp lezen, of van een terminal, of omdat read() onderbroken werd door een signaal). Zie ook OPMERKINGEN.

Bij falen wordt -1 teruggegeven, en errno wordt overeenkomstig gezet. In dit geval is niet bepaald of de plaats in het bestand (als die bestaat) veranderd.

De bestandsbeschrijving bes_ind refereert naar een ander bestand dan de socket en is gemarkeerd als niet-blokkerend (O_NONBLOCK, en de read zou blokkeren. Zie open(2) voor meer details over de O_NONBLOCK vlag.
De bestandsbeschrijving bes_ind refereert naar een socket en werd gemarkeerd als niet-blokkerend (O_NONBLOCK, en de read() zou blokkeren. POSIX.1-2001 staat toe in dit geval een fout te retourneren en vereist niet dat deze constanten dezelfde waarde hebben, waardoor een overdraagbare applicatie op beide mogelijkheden zou moeten controleren.
bes_ind is geen geldige bestandsbeschrijving, of is niet open voor lezen.
buf ligt buiten de door u toegankelijke adres ruimte.
De aanroep werd onderbroken door een signaal voordat enige data werd gelezen; zie signal(7).
bes_ind is gekoppeld aan een object dat ongeschikt is om van te lezen; of het bestand werd geopend met de O_DIRECT vlag en ofwel het adres opgegeven in buf, de waarde opgegeven tel of de bestandsplaats is niet goed uitgelijnd.
bes_ind werd aangemaakt door een aanroep van timerfd_create(2) en de verkeerde buffer grootte werd meegegeven aan read(); zie timerfd_create(2) voor meer informatie.
Invoer/Uitvoer fout. Dit gebeurd bijvoorbeeld als een proces uit een achtergrond-proces-groep probeert van zijn controlerende terminal te lezen en, ofwel het negeert/blokkeert SIGTTIN, ofwel zijn proces-groep is verweesd. Het kan ook optreden als er een laag-niveau Invoer/Uitvoer fout is terwijl er van schijf of tape gelezen wordt. Een andere mogelijke oorzaak van EIO op netwerk bestandssystemen is wanneer een geadviseerd lock werd verwijderd van de bestandsbeschrijving en dat die lock verloren raakte. Zie de Verloren locks sectie van fcntl(2) voor meer details.
bes_ind wijst naar een map.

Andere fouten kunnen optreden afhankelijk van dat wat verbonden is met bi.

POSIX.1-2008.

SVr4, 4.3BSD, POSIX.1-2001.

Op Linux zal read() (en vergelijkbare systeem aanroepen) op zijn hoogst 0x7ffff000 (2,147,479,552) bytes overdragen, en het daadwerkelijk aantal overgedragen bytes retourneren. (Dit is waar op beide 32-bit en 64-bit systemen.)

Bij NFS bestandssystemen zal het lezen van kleine hoeveelheden gegevens de tijdstempel alleen de eerste keer veranderen, volgende aanroepen laten de tijdstempel onveranderd. Dit wordt veroorzaakt door bufferen van bestandskenmerken aan de zijde van de cliënt: de meeste -zo niet alle- NFS cliënten laten het bijwerken van de `atime' aan de server over; als een lees-opdracht dan genoeg heeft aan de cliënt-kant buffer vind er geen lees-opdracht plaats naar de server en blijft de atime dus onveranderd. UNIX gedrag kan verkregen worden door het bufferen aan de zijde van de cliënt uit te schakelen, maar dat zal in de meeste situaties de last op de server flink vergroten, en zijn prestaties nadelig beïnvloeden.

Volgens POSIX.1-2008/SUSv4 Sectie XSI 2.9.7 ("Thread interacties met Reguliere Bestand Operaties"):

Alle volgende functie zullen onderling atomair zijn voor wat betreft de effecten die in POSIX.1-2008 gespecificeerd zijn indien ze werken op reguliere bestanden of symbolische koppelingen: ...

Tussen de achtereenvolgens vermelde API´s staan read() en readv(2). En tussen de effecten die atomair zouden moeten zijn voor alle threads (en processen) zijn aanpassingen aan de bestandspositie. Echter vóór Linux versie 3.14 was dit niet het geval: als twee processen die een open bestandsindicator delen (zie open(2)) een read() (of readv(2)) op hetzelfde tijdstip uitvoeren, dan zijn de Invoer/Uitvoer operaties niet atomair met betrekking tot aanpassen van de bestandspositie, hetgeen erin resulteert dat de lees acties in beide processen (foutief) zou kunnen overlappen in de datablokken die ze zouden verkrijgen. Dit probleem werd opgelost in Linux 3.14.

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

De Nederlandse vertaling van deze handleiding is geschreven door Jos Boersema <joshb@xs4all.nl>, Mario Blättermann <mario.blaettermann@gmail.com> en Luc Castermans <luc.castermans@gmail.com>

Deze vertaling is vrije documentatie; lees de GNU General Public License Version 3 of later over de Copyright-voorwaarden. Er is geen AANSPRAKELIJKHEID.

Indien U fouten in de vertaling van deze handleiding zou vinden, stuur een e-mail naar debian-l10n-dutch@lists.debian.org.

2 mei 2024 Linux man-pages 6.8