.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson. .\" and Copyright (C) 2016 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified Wed Jul 21 22:40:25 1993 by Rik Faith .\" Modified Sat Feb 18 15:27:48 1995 by Michael Haardt .\" Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer : .\" corrected description of effect on locks (thanks to .\" Tigran Aivazian ). .\" Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond .\" Modified 2000-07-22 by Nicolás Lichtmaier .\" added note about close(2) not guaranteeing that data is safe on close. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH close 2 "2. Mai 2024" "Linux man\-pages 6.8" .SH BEZEICHNUNG close \- Dateideskriptor schließen .SH BIBLIOTHEK Standard\-C\-Bibliothek (\fIlibc\fP, \fI\-lc\fP) .SH ÜBERSICHT .nf \fB#include \fP .P \fBint close(int \fP\fIdd\fP\fB);\fP .fi .SH BESCHREIBUNG \fBclose\fP() schließt einen Dateideskriptor, so dass dieser nicht mehr zu einer Datei gehört und wieder verwendet werden kann. Alle zum Prozess gehörenden Datensatz\-Sperren (siehe \fBfcntl\fP(2)) der mit dem Deskriptor verbundenen Datei werden aufgehoben. Die Aufhebung der Sperren erfolgt unabhängig von dem Deskriptor, mit dem die Sperre eingerichtet wurde. Dies hat einige unglückliche Konsequenzen und Sie sollten besonders vorsichtig beim Einsatz von empfohlenen Datensatzsperren sein. In \fBfcntl\fP(2) werden die Risiken und Konsequenzen diskutiert sowie die (wahrscheinlich zu bevorzugenden) Deskriptorensperren für offene Dateien. .P Wenn \fIdd\fP der letzte Deskriptor der zugehörigen offenen Datei ist (siehe \fBopen\fP(2)), werden die zugehörigen Ressourcen freigegeben. War der Datei\-Deskriptor der letzte Verweis auf eine Datei, die mittels \fBunlink\fP(2) entfernt wurde, wird die Datei gelöscht. .SH RÜCKGABEWERT Nach erfolgreicher Ausführung gibt \fBclose\fP() 0 zurück. Bei Fehlern wird \-1 zurückgegeben und \fIerrno\fP gesetzt, um den Fehler anzuzeigen. .SH FEHLER .TP \fBEBADF\fP \fIdd\fP ist kein gültiger Deskriptor für eine geöffnete Datei. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" Der Aufruf von \fBclose\fP() wurde von einem Signal unterbrochen (siehe \fBsignal\fP(7)). .TP \fBEIO\fP Es ist ein E/A\-Fehler (engl. I/O) aufgetreten. .TP \fBENOSPC\fP .TQ \fBEDQUOT\fP Auf NFS werden diese Fehler normalerweise nicht beim ersten Schreibversuch, der den verfügbaren Speicherplatz überschreitet, berichtet, sondern stattdessen an nachfolgende \fBwrite\fP(2), \fBfsync\fP(2) oder \fBclose\fP(2). .P Siehe ANMERKUNGEN für eine Diskussion, warum \fBclose\fP() nach einem Fehler nicht erneut versucht werden sollte. .SH STANDARDS POSIX.1\-2008. .SH GESCHICHTE .\" SVr4 documents an additional ENOLINK error condition. POSIX.1\-2001, SVr4, 4.3BSD. .SH ANMERKUNGEN Ein erfolgreiches »close« garantiert nicht, dass die Daten erfolgreich auf der Festplatte gespeichert wurden, weil der Kernel den Pufferzwischenspeicher verwendet, um verzögert zu schreiben. Typischerweise leeren Dateisysteme ihre Puffer beim Schließen einer Datei nicht. Wenn Sie sicher sein müssen, dass die Daten physisch auf der darunterliegenen Platte gespeichert sind, verwenden Sie \fBfsync\fP(2). (Hierbei kommt es auf die Hardware Ihrer Festplatte an.) .P .\" Der Dateideskriptor close\-on\-exec kann dazu verwandt werden, sicherzustellen, dass ein Dateideskriptor automatisch bei einem erfolgreichen \fBexecve\fP(2) geschlossen wird; siehe \fBfcntl\fP(2) für Details. .SS "Multithreaded\-Prozesse und close()" .\" Date: Tue, 4 Sep 2007 13:57:35 +0200 .\" From: Fredrik Noring .\" One such race involves signals and ERESTARTSYS. If a file descriptor .\" in use by a system call is closed and then reused by e.g. an .\" independent open() in some unrelated thread, before the original system .\" call has restarted after ERESTARTSYS, the original system call will .\" later restart with the reused file descriptor. This is most likely a .\" serious programming error. Wahrscheinlich ist es unklug, Dateideskriptoren zu schließen, die möglicherweise noch durch Systemaufrufe in anderen Threads desselben Prozesses belegt sein können. Da Dateideskriptoren wiederverwendet werden können, kann dies zu undurchsichtigen »Race Conditions« mit unbeabsichtigten Nebenwirkungen führen. .P Betrachten Sie des Weiteren folgendes Szenario, bei dem zwei Threads Aktionen auf den gleichen Dateideskriptor ausführen: .IP (1) 5 Ein Thread blockiert auf einem E/A\-Systemaufruf auf dem Dateideskriptor. Beispielsweise versucht er in eine Pipe zu schreiben (\fBwrite\fP(2)), die bereits voll ist, oder versucht aus einem Datenstrom\-Socket zu lesen (\fBread\fP(2)), der derzeit über keine Daten verfügt. .IP (2) Ein anderer Thread schließt den Dateideskriptor. .P Das Verhalten in dieser Situation unterscheidet sich zwischen Systemen. Auf einigen Systemen kehrt der blockierte Systemaufruf sofort mit einem Fehler zurück, wenn der Dateideskriptor geschlossen wird. .P .\" 'struct file' in kernel-speak .\" Unter Linux (und möglicherweise einigen anderen Systemen) ist das Verhalten anders: Der blockierende E/A\-Systemaufruf hält eine Referenz auf die zugrundeliegende offene Dateideskription und diese Referenz hält die Deskription offen, bis der E/A\-Systemaufruf abschließt. (Siehe \fBopen\fP(2) für eine Diskussion von offenen Dateideskriptionen). Daher kann sich der blockierende Systemaufruf in dem ersten Thread nach einem \fBclose\fP() in dem zweiten Thread erfolgreich beenden. .SS "Umgang mit von close() zurückgelieferten Fehlern" Ein sorgfältiger Programmierer prüft den Rückgabewert von \fBclose\fP(), da es durchaus möglich ist, dass Fehler bei einer früheren \fBwrite\fP(2)\-Operation erst bei dem abschließenden \fBclose\fP()\-Zugriff, bei dem die offenen Dateideskriptoren freigegeben werden, gemeldet werden. Wird der Rückgabewert beim Schließen einer Datei nicht geprüft, kann dies zu \fIunbemerktem\fP Datenverlust führen. Dies kann vor allem mit NFS und Plattenkontingenten beobachtet werden. .P Beachten Sie allerdings, dass ein zurückgelieferter Fehler nur für diagnostische Zwecke (d.h. einer Warnung an die Anwendung, dass E/A noch in Verarbeitung ist, oder dass es fehlgeschlagene E/A gegeben haben könnte) oder für abhelfende Zwecke (z.B. dem erneuten Schreiben der Datei oder dem Erstellen einer Sicherungskopie) verwandt werden sollte. .P .\" The file descriptor is released early in close(); .\" close() ==> __close_fd(): .\" __put_unused_fd() ==> __clear_open_fd() .\" return filp_close(file, files); .\" .\" The errors are returned by filp_close() after the FD has been .\" cleared for re-use. .\" filp_close() Es ist falsch, nach einer Rückgabe eines Fehlers \fBclose\fP() erneut zu versuchen, da es dazu führen könnte, dass ein wiederverwandter Dateideskriptor von einem anderen Thread geschlossen werden könnte. Dies kann auftreten, da der Linux\-Kernel Dateideskriptoren \fIimmer\fP früh in der Close\-Aktion für die Wiederbenutzung freigibt und die Schritte, die einen Fehler liefern können, wie das Rausschreiben von Daten zu dem Dateisystem oder Gerät, erst später in der Close\-Aktion vorkommen. .P .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. .\" Issue 8 Viele andere Implementierunngen schließen den Dateideskriptor ähnlich (außer im Falle von \fBEBADF\fP, der bedeutet, dass der Dateideskriptor ungültig war), selbst falls sie im folgenden einen Fehler bei der Rückkehr von \fBclose\fP() berichten. POSIX.1 sagt derzeit zu diesem Punkt nichts aus, aber es gibt Überlegungen, dieses Verhalten in der nächsten großen Veröffentlichung dieses Standards zu verpflichten. .P Ein sorgfältiger Programmierer, der über E/A\-Fehler Bescheid wissen möchte, kann \fBclose\fP() einen Aufruf von \fBfsync\fP(2) vorschalten. .P Der Fehler \fBEINTR\fP ist etwas speziell. Bezüglich des Fehlers \fBEINTR\fP sagt POSIX.1\-2008: .P .RS Falls \fBclose\fP() von einem Signal unterbrochen wird, das gefangen werden soll, muss es \-1 zurückliefern, wobei \fIerrno\fP auf \fBEINTR\fP gesetzt werden soll und der Zustand von \fIfildes\fP nicht festgelegt ist. .RE .P .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes further changes for EINTR .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=529 .\" .\" FIXME . .\" Review the following glibc bug later .\" https://sourceware.org/bugzilla/show_bug.cgi?id=14627 Dies erlaubt das Verhalten, das auf Linux und vielen anderen Implementierungen auftritt, bei dem, wie auch bei anderen von \fBclose\fP() berichteten Fehlern, garantiert wird, dass der Dateideskriptor geschlossen ist. Es erlaubt allerdings auch eine andere Möglichkeit: dass die Implementierung einen Fehler \fBEINTR\fP zurückliefert und den Dateideskriptor offen hält. (Laut seiner Beschreibung ist dies für \fBclose\fP() unter HP\-UX der Fall.) Der Aufrufende muss dann erneut \fBclose\fP() verwenden, um den Dateideskriptor zu schließen und Lecks bei Dateideskriptoren zu vermeiden. Diese Divergenz in Implementierungsverhalten stellt eine schwierige Hürde für portable Anwendungen dar, da unter vielen Implementierungen \fBclose\fP() nicht nach einem Fehler \fBEINTR\fP erneut aufgerufen werden darf, und bei mindestens einer \fBclose\fP() erneut aufgerufen werden muss. Es gibt Überlegungen, dieses Puzzle für die nächste Hauptveröffentlichung des Standards POSIX.1 zu lösen. .SH "SIEHE AUCH" \fBclose_range\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Ralf Demmer , Martin Eberhard Schauer , Mario Blättermann und Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .