Hi,

I create the file mytest.txt. Since this process is using this file. if I run this code in background and simply run "rm -rf mytest.txt" than file gets delete.
Please help me how to save this file from other process.

Here is my code

int main()
{
FILE *fp;
fp = fopen ("mytest.txt","wb");
if (NULL == fp)
{
return -1;
}
while (1)
{
do_something();
}
return 0;
}

Hello. There is no portable way to do what you want. Should you decide to limit your code to POSIX systems, I believe you could accomplish this task by running your program as a different user than that as which the other (adversary) processes run. Depending on your exact needs, you might also have to give up fopen() in favor of a system call which allows you to specify file permissions (eventually you could couple this with a call to fdopen()).

I usually dislike such things, however: are you sure you actually have the problem which you think you do? Could you give us some more (exact) details regarding what your program does and under what circumstances (and for what reasons) a different process would disrupt your program's functionality?

Thanks for your reply.
I don't want any user to edit/delete my file. e.g in Open office if any file is open it doesn't allow to delete the file.
But if we take the example of wordpad that we can delete the already open file. I decided to stick with POSIX system only.
I tried with flock() and open() call also. I don't want to use chattr +i because it only works with ext2/ext3 file system only.

I don't want to share or delete the file data if it is already opened in the code.
please help me.

Thanks & Regards;
BKP

What operating system does this happen on?

Linux (Fedora 10)

I tried on my Arch system with LibreOffice, and it doesn't stop me from deleting the file, nor does it warn me that it has been deleted.

The simple answer is you cannot prevent a file from being deleted, other than putting it in a place another user cannot delete it (hint homedirectory, properly secured);
However, if you really need that file to be and stay in place, you can periodically check if the file still exists, has been changed or whatever else (even if it has the same inode) and then decide if you want to rewrite the file.

Linux is not stupid windows that holds your hand because it assumes the user is stupid (not that bad an assumption at times) and needs to be reminded etc etc. If you want to delete the file, then you must have good reasons for it, and the system obeys your command to delete it, unless you do not have sufficient rights.

Something that comes relatively close would be the sticky bit on a directory: http://en.wikipedia.org/wiki/Sticky_bit

Your best and most portable defense is probably to either read the file into memory, and work from that version (requires enough memory or small file, and still possibility of deletion during read), or make a temporary copy of the disk file, and use that until the process is ready to close the file, making a new version from the temporary copy. The same possibility of deletion during either copy process exists.
--- rod.

If a file is opened and then deleted the file can still be read; the i-node is actually opened. If the i-node instead is overwritten, I'm not 100% sure what happends during the read, but I guess that data after the filepointer is read as new data, whereas data changed "before" that filepointer is read as the old data, until the filepointer is rewinded to the start; again: this is a guess; I'd have to look up the definitions.

I'm pretty sure using unlink to do this is fully supported.

At the end you could do whatever you want with the file contents before exiting - re-write them to another name, re-create the original file name, etc.

This could go badly under NFS, but if you are using NFS then you already have other locking tools available to you, so you don't need to use code like this anyway.