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

subramanian100in@yahoo.com, India <subramanian100in@yahoo.com> wrote:
> 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.

<subramanian100in@yahoo.com> wrote in message
news:0dd13896-9a15-4c0c-b5ab-287bb60fd8be@v17g2000prc.googlegroups.com=20
> The following question is for learning purpose only.
>=20
> I work on x86 based RedHat Linux and g++3.4.3
>=20
> 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.

On Nov 29, 7:51=A0am, Juha Nieminen <nos...@thanks.invalid> wrote:

> =A0 (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.

On Nov 29, 5:19=A0pm, red floyd <redfl...@gmail.com> wrote:
> On Nov 29, 7:51=A0am, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > =A0 (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. =A0There 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.

"subramanian100in@yahoo.com, India" <subramanian100in@yahoo.com> wrote in 
news:0dd13896-9a15-4c0c-b5ab-287bb60fd8be@v17g2000prc.googlegroups.com:

> 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

In Unix/Linux, this does not remove the file, it just unlinks it from the 
directory tree. There is a remove(3) library function, but this just 
calls unlink(2) for files. Such behavior is needed for supporting hard 
links in the filesystem. In Windows world, NTFS is also supporting 
hardlinks but I think they are not used very often. 

In Windows, the file deletion fails if the file has been opened by some 
other application. They have gone to quite extreme measures to overcome 
this problem, up to introducing a new system call (MoveFileEx()) to 
register the files to be deleted at the restart of the system. So, while 
the Unix 'rm' behavior seems strange and counter-intuitive and can cause 
loss of data, the Windows "intuitive solution" (resulting in system 
reboots) appears to be not better.

I am not sure if there are any OS-es/filesystems where the deletion of 
file causes errors in subsequent writes to that file in a running process 
(as you expected). One can imagine this approach would bring a bunch of 
new problems. For starters, the ownership and access rights of the 
directory and the file therein can be different, but deletion of a file 
mostly concerns the directory.

hth
Paavo