Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignored errors in file handling #24413

Closed
tbu- opened this issue Apr 14, 2015 · 1 comment
Closed

Ignored errors in file handling #24413

tbu- opened this issue Apr 14, 2015 · 1 comment

Comments

@tbu-
Copy link
Contributor

tbu- commented Apr 14, 2015

Currently you cannot handle a potential error of the close syscall on POSIX systems, and of the CloseHandle function on Windows. This means that you cannot reliably write to files, because the errors are also silently ignored.

The man page of close(2) specifically says:

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 with disk quota. Note that the return value should be used only for diagnostics. In particular close() should not be retried after an EINTR since this may cause a reused descriptor from another thread to be closed.

I couldn't find specific information for Windows, but it hinted that CloseHandle might also fail to indicate an error.

I'd like to nominate this bug for 1.0, because this might need backward-incompatible changes to have "sound" support for file writing.

@alexcrichton
Copy link
Member

I believe this is the topic that rust-lang/rfcs#770 is trying to address, so I'm going to close in favor of that RFC.

The current idea is to add fn close(self) -> io::Result<()> which should be a backwards-compatible change to make.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants