why no error for writing into a deleted file

[subramanian100in]

The following question is for learning purpose only.

I work on x86 based RedHat Linux and g++3.4.3

In the following program, I create a temporary file named
'error_log.txt'. Then I do a cin.get() so that the program waits for
some key-press. At this time I open another terminal window and delete
this 'error_log.txt' file created already, by issuing the command:
rm error_log.txt
Now I did 'ls' from the directory where 'error_log,txt' was deleted.
The directory listing did NOT show 'error_log.txt', as expected. Now I
go to the first terminal window where the original program is waiting
for user input. Here I press 'RETURN'. The program tries to write some
contents into the file 'error_log.txt'(which was deleted in the other
terminal window).
Now if I do
if (!ofs)
{
// ...
}
the block of code inside the 'if' is NOT executed. I thought since the
error_log.txt was deleted, the statement
ofs << "test line" << endl;
will result in error for the 'ofs'. But it does not happen.
Why doesn't the operation
ofs << "test line" << endl;
fail (after deleting the error_log.txt' through another terminal
window)? I cannot understand this. Kindly explain. What is the
expected bahaviour ?

Here is the complete program z.cpp

#include <cstdlib>
#include <ostream>
#include <istream>
#include <iostream>
#include <fstream>

using namespace std;

int main()
{
ofstream ofs("error_log.txt");

if (!ofs)
{
cout << "Could not create the file: error_log.txt"
<< endl;
exit(EXIT_FAILURE);
}

cin.get();

ofs << "test line" << endl;

if (!ofs)
{
cout << "Error encountered while logging error in "
"the file: error_log.txt"
<< endl;
exit(EXIT_FAILURE);
}

return EXIT_SUCCESS;
}

This program compiles fine with g++3.4.3 as
g++ -std=c++98 -pedantic -Wall -Wextra z.cpp

Thanks
V.Subramanian

 

[Juha Nieminen]

I cannot understand this. Kindly explain. What is the
expected bahaviour ?

Even if you remove a file in Linux (with 'rm' or whatever), Linux won't
physically remove it as long as any program has an open handle to it. It
will be physically removed only after the last program which has an open
handle to it releases it. The file won't show with 'ls' and it cannot be
opened (eg. by a new program), but it will still be there, waiting for
it to be released. Only after that will the system finally mark it as
completely removed.

(I don't remember now, however, if this is related to Linux itself or
to the specific file system you are using.)

This behavior is system-specific so it should not be relied on in
portable programs.

 

[Fred Zwarts]

The following question is for learning purpose only.

I work on x86 based RedHat Linux and g++3.4.3

In the following program, I create a temporary file named
'error_log.txt'. Then I do a cin.get() so that the program waits for
some key-press. At this time I open another terminal window and delete
this 'error_log.txt' file created already, by issuing the command:
rm error_log.txt
Now I did 'ls' from the directory where 'error_log,txt' was deleted.
The directory listing did NOT show 'error_log.txt', as expected. Now I
go to the first terminal window where the original program is waiting
for user input. Here I press 'RETURN'. The program tries to write some
contents into the file 'error_log.txt'(which was deleted in the other
terminal window).
Now if I do
if (!ofs)
{
// ...
}
the block of code inside the 'if' is NOT executed. I thought since the
error_log.txt was deleted, the statement
ofs << "test line" << endl;
will result in error for the 'ofs'. But it does not happen.
Why doesn't the operation
ofs << "test line" << endl;
fail (after deleting the error_log.txt' through another terminal
window)? I cannot understand this. Kindly explain. What is the
expected bahaviour ?

The behaviour is very opeating system dependent.
I think that for e.g. Windows, a very different behaviour is observed.
So, you will get better answers when this question is placed in a Linux newsgroup.

 

[red floyd]

  (I don't remember now, however, if this is related to Linux itself or
to the specific file system you are using.)

It's portable among *nix. There are no links to the file in the file
system, but the inode still hangs around in core.

 

[gwowen]

It's portable among *nix.  There are no links to the file in the file
system, but the inode still hangs around in core.

Which isn't to say you won't get different/peculiar behaviour,
particularly on NFS or Samba shares, where the Unix semantics are not
necessarily supported.