Any-FS-I/O generally is not fast (except ramdisk).
Since a valid fd implicates a existing file i think there is no such test.
But write should return error or at leas a less count of bytes written.
You can set the O_DSYNC while calling open, which at least should block the process while writing and therefor tell you if bytes were actually really written.
Another option is to lock the file, this would prevent it from being deleted in the first place.
I yet never came to an point where my file was deleted during writing ^^.
fd = open(name)
unlink(name)
read(fd, buf, buf_size)
what is the return value of the read() ?
from my understanding function open() does several things
open() passes the request to the process responsible for path name/namespace defined by “name”, lets call the process “io manager”
the io manager creates/opens an object context (file/dir/link/network connection/memory/special device/whatever)
open() creates a fd in the calling process
open() assigns this fd to that object context in the io manager
now you call unlink()
unlink() passes the request to the io manager
the io manager removes the association of the “name” to the “object context”
well, now you cannot open() or stat() the “name” but what about read()/write() ?
read()/write() passes the request to the io manager
io manager does the work (in case of a real file in a filesystem on a block device it probably even really reads/writes the data from/to the hardware) and replies that it has completed the operation
The io manager is actually not required to return error if the “name” is no longer part of the “filesystem/whatever”
oink:
There is fstat(fd) but it operates on the file descriptor so you cannot really know if the file still exists that way
Use stat() …
If I understand the poster correctly,
A process opens a file for write.
After it is opened, the file is deleted.
The process writes data to the file, and then closes it.
At this point the file does not exist.
This is the correct expected Posix behavior. This is exactly how a “temp” file works.
To answer the final question of the poster
"How can I know if file that I open() does’n exist (has been removed) ? "
one would have to know from who’s perspective?
From the opener it exists, but from any other process, it doesn’t.
Just to be anally correct here, this process could fork or spawn
other processes that would be able to access the file.
So for a 2nd process to find out if it exists to the first process, it would have to ask the first process.
Another process has no way to access it.
When the file is finally closed it ceases to exist.
So the first process can write all the data it wants to
the file. In fact it could fill up the disk and get
a “no more disk space” error, but once closed the file would dissappear.
As I said, the behavior is exactly as expected, and this is not a bug. Try it on Linux and see. There is no reason for an I/O error. The process that opened the file can write all it wants. If it rewinds, it can read it. If enough time goes by, the data will even get to disk. But when the file is closed, the OS, or rather the file system will recover the data. You have to get past the idea that a file has to have a directory entry. In your case, there was a directory entry, but since the file was open when the directory entry was removed, the file continues to exist, although it is available only the the process that has it open.
You can avoid passing in the path (and hence the somewhat heavy path resolution) by using fstat(). The st_nlinks field will be zero if the file is gone.