Can a file be deleted even if it is in use.

Hi
I am using Red Hat Linux 9 and gcc 3.4
I have created an application in C which has some file handling
associated to it. The application starts with opening a file using
fopen() in binary write mode. The file is open untill the application
exits.
Though my application is running I am able to delete the file created
using rm -f <filename>.
According to my knowledge the Operating System shouldn't have allowed
any other application to delete a file if it is in use.

Please correct me, and give me inputs for clarifying this concept.

Thanks
Aditya

>I am using Red Hat Linux 9 and gcc 3.4
>I have created an application in C which has some file handling
>associated to it. The application starts with opening a file using
>fopen() in binary write mode. The file is open untill the application
>exits.
>Though my application is running I am able to delete the file created
>using rm -f <filename>.

This is quite normal.  It also doesn't prevent the application using
the file from writing it, reading it, or growing it so big it runs
the disk out of space.  It can't re-open it by name as the file no longer
has a name.

>According to my knowledge the Operating System shouldn't have allowed
>any other application to delete a file if it is in use.

Why?

In that case, you'd need rm -f,dammit <filename> which
kills anything using the file, then deletes it, and
rm -f,dammit,dammit <filename> which kills anything using the
file, then deletes it, and deletes the offending users that were
using the file.

The only thing close to this in Unix systems is prohibition of deleting
or opening for write a running executable.

On Mar 31, 10:11=A0am, gordonb.yi...@burditt.org (Gordon Burditt) wrote: 
>
> This is quite normal. =A0It also doesn't prevent the application using
> the file from writing it, reading it, or growing it so big it runs
> the disk out of space. =A0It can't re-open it by name as the file no longe=[/color
]
r
> has a name.
> 
>
> Why?
>
> In that case, you'd need rm -f,dammit <filename> which
> kills anything using the file, then deletes it, and
> rm -f,dammit,dammit <filename> which kills anything using the
> file, then deletes it, and deletes the offending users that were
> using the file.
>
> The only thing close to this in Unix systems is prohibition of deleting
> or opening for write a running executable.

Thanks
Sorry I missed a second thought on the second part. rm -f has to be
that way.

But then how can the behaviour of the application be modified so that
the fwrite() or fs() calls do give me the indication of the file
been deleted.

Aditya <adityagupta.18@gmail.com> writes:
> I am using Red Hat Linux 9 and gcc 3.4
> I have created an application in C which has some file handling
> associated to it. The application starts with opening a file using
> fopen() in binary write mode. The file is open untill the application
> exits. Though my application is running I am able to delete the file
> created using rm -f <filename>.
>
> According to my knowledge the Operating System shouldn't have
> allowed any other application to delete a file if it is in use.

The file hasn't been deleted. One of the names ('links') pointing to
it has been removed from the filesystem.

On Mar 31, 2:02=A0pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> Aditya <adityagupta...@gmail.com> writes: 
> 
>
> The file hasn't been deleted. One of the names ('links') pointing to
> it has been removed from the filesystem.

So, The problem still persists. How do I ensure that anything written
doesn't go anywhere other than the file I open using fopen(), or I get
some return value from these system calls where I can know that the
file is not there to be written(or the links has been removed).

Aditya wrote:
> On Mar 31, 2:02 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: 
>
> So, The problem still persists. How do I ensure that anything written
> doesn't go anywhere other than the file I open using fopen(), or I get
> some return value from these system calls where I can know that the
> file is not there to be written(or the links has been removed).

By using a file locking mechanism.  For the concept of file locking:
http://en.wikipedia.org/wiki/File_l...locking_in_UNIX

Aditya <adityagupta.18@gmail.com> writes:
> On Mar 31, 2:02_pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: 
>
> So, The problem still persists. How do I ensure that anything written
> doesn't go anywhere other than the file I open using fopen(), or I get
> some return value from these system calls where I can know that the
> file is not there to be written(or the links has been removed).

You are misunderstanding something here. Somewhat simplified, 'a file'
corresponds to an i-node ('index node') on UNIX(*), which is an
on-disk data structure containing metainformation regarding the file
(eg access permissions and a reference count) and pointers to the disk
blocks containing the file content. When doing I/O-operations on some
file, a program uses a 'file descriptor' ([usually] small, positive
integer) to tell the kernel which file to access. This file descriptor
ultimatively resolves to the i-node of the file.

So, how does the program acquire a file descriptor for some file? The
answer to this question is 'by doing an open-syscall, passing a
certain pathname which identifies the file to access'. The i-node
itself does not have a name. But multiple directory entries ('links')
can point to it, each enabling access to the file using a different
name. The file reference count in the i-node is used to track the
number of existing links to it and the number of currently open file
descriptors refering to the file associated with the i-node. When this
reference count drops to zero, the space occupied by the file is
deallocated (made available for future use to store the contents of
different files). If an unlink system calls is executed, eg because
a users ran the rm-command, a particular link is deleted from the
filesystem and the reference count of the file the link had referred
to is decremented. If that is still larger than zero afterwards, eg
because some program has an open descriptor for the file, nothing else
happens.

For your situation, this means that your programm will continue to
write to the same file you originally openend, but that names
associated with this file can be created or removed while the program
is using it.

Nikos Chantziaras <realnc@arcor.de> writes:
> Aditya wrote:

[...]
 
>
> By using a file locking mechanism.  For the concept of file locking:
> http://en.wikipedia.org/wiki/File_l...locking_in_UNIX

I would be strongly advisable that you read this yourself before
referring others to it.

On Mar 31, 2:24 pm, Aditya <adityagupta...@gmail.com> wrote:
> On Mar 31, 2:02 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> 
> 
> 
>
> So, The problem still persists. How do I ensure that anything written
> doesn't go anywhere other than the file I open using fopen(), or I get
> some return value from these system calls where I can know that the
> file is not there to be written(or the links has been removed).
By setting the permissions (umask(2), open(2), chmod(2))
Would you imagine how annoying it would be if the OS prevented the
user from deleting his *own* files?
I suggest that instead of making sure that the file will be there you
make sure the behavior of your application is defined *if* the file is
not there.

On Mar 31, 4:24 am, Aditya <adityagupta...@gmail.com> wrote:

> So, The problem still persists.

What *exactly* is the problem? Everything you've described is the
expected behavior.

> How do I ensure that anything written
> doesn't go anywhere other than the file I open using fopen(),

The system ensures that. Even if the file is unlinked and a new file
created with the same name, everything you write still goes to the
file you opened.

> or I get
> some return value from these system calls where I can know that the
> file is not there to be written(or the links has been removed).

The file is always there to be written once you've opened it for
writing. It will not go away until you close it. If you want to check
the directory you used to access the file, you can do that. Google
'file alteration monitor'.

However, a file can have more than one name in a filesystem. That the
name you used to open has gone away does not mean the file cannot be
accessed by other names.

DS