1

Re this quetion: Does close() call fsync() on Linux?

This question describes that close() (c lib) does not call sync on linux.

Is this the same for fstream::close()?:

http://www.cplusplus.com/reference/fstream/fstream/close/ suggests that is does write all the remaining bytes to file. I have observed (rare) cases where I finish writing a block of 2-3KB to a file, call fs.close() and then try to open it and the open fails. Adding a short delay and/or calling sync seems to cure this.

So I think I have answered my own question, but the std::fstream::close() description confuses me

code_fodder
  • 15,263
  • 17
  • 90
  • 167
  • AFAIK `sync` should not affect this. I think you should look elsewhere for the cause of your problems. – Nate Eldredge Jun 17 '20 at 14:52
  • 2
    What do you mean opening fails? Fails how? `fsync` has nothing to do with flushing data to a file, but causes writing data to an underlying device. –  Jun 17 '20 at 14:52
  • @StaceyGirl fails like: `std::ifstream ifs {filename, in | binary}; if (!ifs) {...fail...}` I run this right after I closed it having written all the data. – code_fodder Jun 17 '20 at 15:02
  • @code_fodder It should not fail. Whatever you are doing, it has nothing to do with `sync`, `fsync` etc. Unless it involves some faulty network storage or running under Linux Subsystem for Windows or something like that. –  Jun 17 '20 at 15:10
  • @StaceyGirl I saw this once on an ubuntu VM, but mostly I see this running on linux in a jenkins test environment. But its rare. All I am really doing is writing to an ofstream and reading back using ifstream - simple stuff. The answers below suggest it *could* be an issue... – code_fodder Jun 17 '20 at 15:12
  • @code_fodder None of 2 answers suggest that. Regardless of whether data is on device or not, the OS has to maintain the same view of filesystem e.g. caching is transparent. –  Jun 17 '20 at 15:14
  • @StaceyGirl... hmm, then I am at a loss as to what is going on here... :( – code_fodder Jun 17 '20 at 15:16
  • @StaceyGirl also calling sync does fix it ... empirical evidence? – code_fodder Jun 17 '20 at 15:16
  • @code_fodder I think `sync` will work just as good as `usleep`. –  Jun 17 '20 at 15:17
  • @StaceyGirl do you have a theory why any delay might be needed? - other then memory types. This is running on a desktop PC SSD - flash mem? – code_fodder Jun 17 '20 at 15:18
  • @code_fodder You are mistakenly assuming that filesystem view has anything to do with physical device - it doesn't. Opening, reading, writing doesn't even touch the device most of the time, instead it gets information from a RAM (file cache). So `fsync` should not have any visible side aside from preserving your data after power loss. –  Jun 17 '20 at 15:24
  • @StaceyGirl well, I won't argue with you there, but I can just point to my evidence... I have not printed the code, but its really simple ifstream ofstream code. I know the data is 100% correct because its binary files that I can binary compare and even execute. I have written files from a few bytes to 100's MB with no data corruption of any sort. I cant think of anything unusual then re-opening the file right away (which is generally an uncommon thing to do). So I think the answers below do answer *this* qusetion, I am thinking my issue is a slightly different question! – code_fodder Jun 17 '20 at 15:31

2 Answers2

2

It might depend on the library implementation, but for common ones, it does not. What is written in ccpreference, means that the internal stream buffer writes any pending bytes before closing. But it does not request the os file system driver to force an immediate write on the disk device.

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • ah, ok - that makes sense - it sounds similar to c style close() then - I guess they are roughly the same under the hood. So if you are writing to a file and close it and you know you want to read again from it immediately calling the linux OS sync might be required? – code_fodder Jun 17 '20 at 15:00
  • @code_fodder: It should not be required. After closing a file you should be able to re-open it immediately. If you experience a problem there, it is in fact a quite different question. – Serge Ballesta Jun 17 '20 at 15:35
  • yes I just realised that (and commented in the main comment block) as you say, this Question has an answer thanks : ) – code_fodder Jun 17 '20 at 15:38
1

does ofstream::close() call sync ...

It will flush the buffers that are internal to the stream, and the closes it. Whether something comparable to sync or fsync is called is unpecified.

... on linux?

This is up to the implementation. Thus, it may depend on which standard library implementation you use. If you use an open source one, you can take a look at the source to see what it does.

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • I am using the gcc libs on ubuntu. I don't think I have the source available there, but I am sure I can look that up, thanks : ) – code_fodder Jun 17 '20 at 15:10
  • @code_fodder The sources are in the gcc-${version}-source package. They are also in several publicly accessible repositories on the internet. – eerorika Jun 17 '20 at 15:12
  • I had a look in the source. It does call its own "sync()" function, but that just finishes off writing to the file (as far as I can tell - not that great at reading the std libs). So I do not think it does a sync at os level. Thanks for the hint for the source code :) – code_fodder Jun 17 '20 at 15:33