Hi all

I have some dough regarding permission issue i.e
Firstly creating a file after file creation remove all the permission of that file
that time I can access the file or not.

No, not as a user. Simple test I did which you can do. In your /home/user directory create a text file: touch testfile. Open it in a text editor and enter some random info. Change permissions: chmod 000 testfile Check the permissions: ls -l testfile, should show all dashes, no permissions. Open it in a text editor, it won't open and you get an error. Open it as root and it opens and can be edited.

Actually, you can open it in vi(m), but you get a warning. You can also edit it BUT to save changes you'll need to append '!' to the usual 'x' (or 'w').
Also, you can still change the perms back (assuming you own the enclosing dir).

@OP: Best thing to do with a qn like that is to try it

What actually happens is that the original file is deleted.

After all you are creating a new file...

Now, most utilities will not create a new file - instead they will truncate the original file, and open the file for writing. But that doesn't create a new file, though the distinction is rather small.

I'm not the OP, but I lost you there...

You're saying if you change permissions to 000 you create a new file?

Depends on how the file gets opened.

Normally, you can't delete the file - and the open fails.

Some of the older editors (at least used to) delete/rename the file (to have a backup), then open a new one. Current editors appear to open with truncate when they write a new file... vi can write the file even if the access mode is 000 and it is the owner writing it (the w! form) without changing the file. nano (with -B) copies the file to create the backup instead of renaming.

The linker (at least when invoked by gcc) will delete the old executable file and create a new one. So even if the old file had 000 on it, it will be replaced. (In my quickie test, it also gets a new inode).

If the file modes were 000 and the file after whatever operation the OP did has a different access mode, then the file likely got deleted and a new one created. Could even get the same inode number, though I would think that would be rather rare.

Files used for locks get strange (preventing race conditions is tricky).

Now the base system call will not delete the file if O_CREAT is used. If not specified (the usual case), then the existing file may be opened with modes determined by default.

Language runtimes can do different things - it depends on the runtime and language definition then.