2

I try to test the following situation: a file is opened for write, then the file is removed and then something is written to the opened. Here is the source code:

    std::ofstream stream("a.txt");
    std::string a("before");
    stream.write(a.c_str(), a.size());
    stream.flush();
    std::filesystem::remove("a.txt");
    std::cout << stream.good() << std::endl;
    std::string b("after");
    stream.write(b.c_str(), b.size());
    stream.flush();
    std::cout << stream.good() << std::endl;

The program works in the expected way: the file does not exist after the execution. Nevertheless, none of fail flags is set and the stream is considered as a good one. Why?

P.S. OS: Ubuntu 20.04, Compiler g++ 9

Кирилл Волков
  • 372
  • 1
  • 11
  • It's because you're using Linux? – Sam Varshavchik Sep 26 '22 at 15:08
  • 2
    This is OS dependent but opening a file may 'lock' it so that the deletion only happens after the file is closed. On other operating systems it would be the `remove` that fails not the `write`. – john Sep 26 '22 at 15:09
  • Not a reason why the flags aren't set, but have you tried using the `is_open` function on the `ofstream`? – cs1349459 Sep 26 '22 at 15:09
  • @cs1349459 yes, true is returned – Кирилл Волков Sep 26 '22 at 15:10
  • @john remove returns success and if I run it in debug mode (so that I can manually check whether the file exists), the file disappears directly after remove call – Кирилл Волков Sep 26 '22 at 15:12
  • @КириллВолков Ok, that is weird. Have you tried refreshing the `ofstream`, by reconstructing it? – cs1349459 Sep 26 '22 at 15:14
  • @КириллВолков That's surprising to me, but we are in OS and implementation specific territory. You should at least say what OS and compiler you are using. My advice would be to use your debugger to step into the `remove` and `write` code to see what is really happening. – john Sep 26 '22 at 15:16
  • @cs1349459 if I create a new stream, then the file is recreated with the only "after" string - it is the expected behaviour – Кирилл Волков Sep 26 '22 at 15:17
  • @john Ubuntu 20.04, g++ 9 – Кирилл Волков Sep 26 '22 at 15:22
  • @КириллВолков You might find [this](https://stackoverflow.com/questions/31099347/what-happens-internally-when-deleting-an-opened-file-in-linux) useful – john Sep 26 '22 at 15:24
  • 1
    @КириллВолков Basically it seems to confirm what I said, but with the additional detail that open but unlinked files still exist but are not visible in any directory. News to me, but it agrees with what you have observed. – john Sep 26 '22 at 15:27
  • @john yes, it seems to explain the behavior – Кирилл Волков Sep 26 '22 at 15:33
  • 2
    See: https://stackoverflow.com/a/185903/14065. The file system and your application both have a reference to the underlying inode that represents the file. If you delete the file from the file system, one link is removed from the inode but the inode still exists. So you can continue to write to it. Once you close the file that last link to the inode is gone and the file system can now delete the underlying data. – Martin York Sep 26 '22 at 15:37

0 Answers0