|
|
|
|
|
by ziffusion
4920 days ago
|
|
What if an ioctl is trying to indicate that a certain "entry" is not valid or available? Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense. Insisting that ENOENT is reserved for path operations seems asinine. |
|
I don't understand the question. It is not possible for ioctl to be called on a valid, open file descriptor that represents a file that is not valid or available. Even if the file is unlinked after being opened, the kernel will ensure that it remains available to any processes that have it open until they close the file descriptor.
Like when it is returning a cached entry or dealing with some container, where a notion of an entry does make sense.
I honestly don't know what you mean by this. ioctls, like nearly all Unix system calls, are file system operations, they necessarily and by definition refer to files.
Insisting that ENOENT is reserved for path operations seems asinine.
On the contrary, ENOENT has meant "No such file or directory" since the early days of Unix history. Arbitrarily deciding to redefine it now would be asinine. There are other errno values to represent other error conditions.