close(2)

NAAM
close - sluit een bestandsindicator

BIBLIOTHEEK
Standaard C bibliotheek (libc, -lc)

SAMENVATTING
#include <unistd.h>

int close(int bi);

BESCHRIJVING
close() sluit een bestandsindicator, zodat deze niet langer naar een bestand wijst en hergebruikt kan worden. Eventuele record sloten op het bestand (zie fcntl(2)) die het eigendom waren van het proces worden verwijderd (onafhankelijk van de bestandsindicator die gebruikt werd om het slot te verkrijgen). Dit heeft enkele nare consequenties en men moet extra voorzichtig zijn bij het gebruik van advies record sloten. Zie fcntl(2) voor een discussie van de risico´s en consequenties en ook over de (mogelijk geprefereerde) open bestandsindicator sloten.

Als bi de laatste dubbelganger van een bepaalde bestandsindicator is, worden de systeem-middelen die erbij horen vrijgemaakt; als de bestandsindicator de laatste verwijzing was naar een bestand dat verwijderd werd met unlink(2) dan wordt het bestand verwijderd.

EIND WAARDE
Bij succes geeft close() nul terug. Bij falen wordt -1 teruggegeven en wordt errno overeenkomstig gezet.

FOUTEN

EBADF
    bi is geen geldige open bestandsindicator.

EINTR
    De close() aanroep werd onderbroken door een signaal; zie signal(7).

EIO Een Invoer/Uitvoer fout trad op.

ENOSPC
EDQUOT
    Op NFS worden deze fouten normaliter gerapporteerd tegen de eerste schrijf actie die de beschikbare opslag ruimte overschrijdt, maar in plaats daarvan tegen een volgende write(2), fsync(2), of close().

See CAVEATS for a discussion of why close() should not be retried after an error.

STANDAARDEN
POSIX.1-2008.

HISTORIE
4.3BSD, SVr4, POSIX.1-1988.

OPMERKINGEN
De sluit-bij-uitvoeren bestandsindicator vlag kan worden gebruikt om er voor zorg te dragen dat een bestandsindicator automatisch wordt gesloten bij een succesvolle execve(2); zie fcntl(2) voor details.

CAVEATS
Een succesvolle close() garandeert niet dat de gegevens succesvol zijn bewaard op de schijf doordat de kernel het schrijven ervan achterhoudt. Het is niet normaal voor een bestandssysteem om de buffers door te spoelen als het bestand wordt gesloten. Als u zeker moet zijn dat de gegevens fysiek bewaard zijn, gebruik dan fsync(2). (Het hangt nu verder van de schijf hardware af.)

  Multithreaded processen en close()
Het is hoogstwaarschijnlijk niet slim om bestandsindicatoren te sluiten terwijl ze in gebruik kunnen zijn door systeem aanroepen in andere threads in hetzelfde proces. Omdat een bestandsindicator kan worden hergebruikt, zijn er obscure looptijd condities die tot onbedoelde neven effecten kunnen leiden.

Bovendien, overweeg het volgende scenario waar twee threads dezelfde operaties op dezelfde bestandsindicator uitvoeren:

(1) Een thread wordt geblokkeerd door een Invoer/Uitvoer systeem aanroep op de bestandsindicator. Bijvoorbeeld, hij probeert te write(2) naar een pijp die al vol is, of probeert te read(2) van een stream socket die op dit moment geen gegevens beschikbaar heeft.

(2) Een andere thread sluit de bestandsindicator.

Het gedrag in deze situatie varieert over systemen. Op sommige systemen, zal de blokkerende systeem aanroep onmiddellijk met een fout beëindigen zodra de bestandsindicator is gesloten

Op Linux (en mogelijk enkele andere systemen), is het gedrag anders: de blokkerende Invoer/Uitvoer systeem aanroep houdt een referentie naar de onderliggende bestandsindicator open, en deze referentie houdt de indicator open totdat de Invoer/Uitvoer systeem aanroep eindigt. (Zie open(2) voor een discussie over open bestandsindicatoren.) Dus kan de blokkerende systeem aanroep in de eerste thread succesvol eindigen na de close() in de tweede thread.

  Omgaan met fout meldingen van close()
Een zorgvuldige programmeur controleert de uitvoer waarde van close(), omdat het mogelijk is dat fouten van een vorige write(2) operatie alleen worden gerapporteerd bij de finale close() die de open bestandsindicator vrij geeft. Het niet controleren van de uitvoer waarde bij het sluiten van een bestand kan leiden tot zwijgend verlies van gegevens. Dit kan speciaal optreden met NFS en met schijf quota.

Merk op, dat een fout uitvoer alleen gebruikt mag worden voor diagnose (m.a.w. een waarschuwing aan de applicatie dat er nog een Invoer/Uitvoer bezig kan zijn of dat er gefaalde Invoer/Uitvoer kan zijn) of gebruikt voor reparaties (b.v. het opnieuw schrijven van een bestand of het maken van een backup).

Opnieuw close() proberen na terug melding van een fout is verkeerd om te doen, omdat dat er voor kan zorgen dat een hergebruikte bestandsindicator van een andere thread kan worden gesloten. Dit kan optreden doordat de Linux kernel de bestandsindicator altijd vroeg tijdens de close operatie los laat, daarbij hem voor hergebruik beschikbaar maakt; de stappen die een fout kunnen geven, zoals doorspoelen van data naar het bestandssysteem of apparaat, treden alleen later tijdens de close operatie op.

Many other implementations similarly always close the file descriptor (except in the case of EBADF, meaning that the file descriptor was invalid) even if they subsequently report an error on return from close(). POSIX.1-2008 was silent on this point.

Een zorgvuldige programmeur die Invoer/Uitvoer fouten wil weten mag de aanroep van close() vooraf laten gaan met een aanroep van fsync(2).

The EINTR error is a somewhat special case. Regarding the EINTR error, POSIX.1-2008 said:

    If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to EINTR and the state of fd is unspecified.

This permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by close(), the file descriptor is guaranteed to be closed. However, it also permits another possibility: that the implementation returns an EINTR error and keeps the file descriptor open. (According to its documentation, HP-UX's close() does this.) The caller must then once more use close() to close the file descriptor, to avoid file descriptor leaks. This divergence in implementation behaviors provides a difficult hurdle for portable applications, since on many implementations, close() must not be called again after an EINTR error, and on at least one, close() must be called again.

POSIX.1-2024 standardized the behavior of HP-UX, making Linux and many other implementations non-conforming. There are no plans to change the behavior on Linux.

ZIE OOK
close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3)

VERTALING
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 (https://www.gnu.org/licenses/gpl-3.0.html) 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.