4 ms·
Rust has the same problem. Files are closed in `Drop` when the value goes out of scope, but all errors are silently ignored. To solve this there's `sync_all`[0]
by K0nserv 2y ago
Rust has the same problem. Files are closed in `Drop` when the value goes out of scope, but all errors are silently ignored. To solve this there's `sync_all`[0].
Generally, relying on defer in Go or Drop in Rust for anything that can fail seems like an anti-pattern to me.
0: https://doc.rust-lang.org/std/fs/struct.File.html#method.sync_all https://doc.rust-lang.org/std/fs/struct.File.html#method.syn...
- kzrdude 2y agoAn ownership consuming close(self) would make sense, but has not been added, there must be some good reason for that?
- masklinn 2y agoThat nobody has gone through the effort of collating its requirements and writing an RFC after https://github.com/rust-lang/rfcs/pull/770 https://github.com/rust-lang/rfcs/pull/770 was closed (back in 2015). I assume a big issue is that this is full of edge cases up the ass, and the value is somewhat limited in the sense that if you know you want durable writes you'll sync() and know you're fucked if you get an error, but close() does not guarantee a sync to disk, as the linux man page indicates: > A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes. So you'd need a "close", and a "close_sync", and possibly also a "close_datasync" (if you're ok with discarding metadata). And one could argue at that point `close` has essentially no value beyond hopefully getting rid of the fd / handle, and drop already does a fine job of that.
- Arch485 2y agoIIRC the Rust book talks about files automatically being closed when dropped, and how that's better than having a close method. That's probably why it's not a separate method, even though it suppresses errors.