Code:int fd = open(fname, O_RDWR|O_CREAT, 0777); unlink(fname); write(fd,"abcd",4);
Code:int fd = open(fname, O_RDWR|O_CREAT, 0777); unlink(fname); write(fd,"abcd",4);
What kind of question is it?
this is not C++ - plain C
unlink is not a standard function - so it should be on specific forum
You do not explain your problem
You think all people here are mind readers or what?
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
unlinking a file doesn't make the open descriptor invalid. It just makes it disappear from the directory structure. Once that fd gets closed, the file goes away "for real."Originally Posted by meili100
Suppose unlink() did actually refuse to delete the file, how would you know? You are not checking the return value.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I doubt the unlink() is failing -- I think the OP might be confused about why the file descriptor is apparently still valid after unlinking the file. It's just standard UNIX behavior.
Yes, I completely agree - there is a reference count [1] on the number of processes holding the file open. When the last process closes the file, it goes away.
I was just trying to point out that if unlink DIDN'T work because a file is open (which is the more likely scenario than the fact that write fails in any way when the file is already opened - unlink should not CLOSE an open file if it can't delete an opened file - it should fail to delete the file).
[1] I beleive it's actually the inode of the file that has a reference count. But I may be wrong.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
