NAME 名字

close - 關閉一個文件描述符  

SYNOPSIS 總覽

#include <unistd.h>

int close(int fd);

DESCRIPTION 描述

close 關閉 一個 文件 描述符 , 使它 不在 指向 任何 文件 和 可以 在 新的 文件 操作 中 被 再次 使用. 任何 與 此 文件 相關聯 的 以及 程序 所 擁有 的 鎖 , 都 會 被 刪除 (忽略 那些 持有 鎖 的 文件描述符)

假如 fd 是 最后 一個 文件描述符 與此 資源 相 關聯 , 則 這個 資源 將 被 釋放. 若此 描述符 是 最后 一個 引用 到 此 文件 上 的 , 則 文件 將 使用 unlink(2) 刪除.  

RETURN VALUE 返回值

close 返回 0 表示 成功 , 或者 -1 表示 有 錯誤 發生 .  

ERRORS 錯誤信息

EBADF

fd 不是 一個 有效 的 已 被 打開 的 文件 的 描述符

EINTR

The close() 調用 被 一 信號 中斷.

EIO

I/O 有 錯誤 發生

CONFORMING TO

SVr4, SVID, POSIX, X/OPEN, BSD 4.3. SVr4 documents an additional ENOLINK error condition.  

NOTES 注意

通常 不檢測 返回值 , 除了 發生 嚴重 的 程序 錯誤. 文件系統 使用 了 "write-behind" 的 技術 提高 了 執行 write(2) 時 的 性能 . 即使 還 沒有 被 寫 , 寫操作 也會 成功 . 錯誤 信息 在 寫操作 以后報告 , 但是 這 保證 在 關閉 文件 時 報告 . 在 關閉 文件 時 不檢測 返回值 可能會 導致 數據 的 丟失 . 這 一點 在 NFS 和 磁盤 配額 上 比較 明顯.

由于 內核 會 延遲 寫 , 所以 就算 成功 關閉 一個 文件 不能 保證 數據 被 成功 的 寫到 磁盤 上. 當 文件流 關閉 時 , 對 文件系統 來說 一般 不去 刷新 緩沖區 . 如果 你 要 保證 數據 寫入磁盤 等 物理 存貯器 中就 使用 fsync(2) 或 sync(2), 他們 會 做到 你想做的 (對于 這一點 要 依賴于 磁盤 設備).  

SEE ALSO 參考

open(2), fcntl(2), shutdown(2), unlink(2), fclose(3)

#p#

NAME

close - close a file descriptor  

SYNOPSIS

#include <unistd.h>

int close(int fd);

DESCRIPTION

close closes a file descriptor, so that it no longer refers to any file and may be reused. Any locks held on the file it was associated with, and owned by the process, are removed (regardless of the file descriptor that was used to obtain the lock).

If fd is the last copy of a particular file descriptor the resources associated with it are freed; if the descriptor was the last reference to a file which has been removed using unlink(2) the file is deleted.  

RETURN VALUE

close returns zero on success, or -1 if an error occurred.  

ERRORS

EBADF

fd isn't a valid open file descriptor.

EINTR

The close() call was interrupted by a signal.

EIO

An I/O error occurred.

CONFORMING TO

SVr4, SVID, POSIX, X/OPEN, BSD 4.3. SVr4 documents an additional ENOLINK error condition.  

NOTES

Not checking the return value of close is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close. Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and disk quotas.

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a filesystem to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)  

SEE ALSO

open(2), fcntl(2), shutdown(2), unlink(2), fclose(3), fsync(2)