> Returning ENOENT when the parent exists is not compliant. This is the
> type of kernel bug that's really annoying for application developers. "Oh,
> if it's linux then I have to retry my open() in user-space if I get ENOENT
> because they've got some fancy locking scheme and don't want to spend a
> few cycles in the kernel being compliant"...
Hi Dean,
You might want to look at a few of the cases more closely before deciding that the
kernel developers are just being lazy or parsimonious with CPU cycles. The ENOENT
doesn't mean that the parent directory doesn't exist -- it means that the file that
_used to exist_ is no longer in this directory, having been renamed or deleted.
Does retrying the operation mean retrying with the original filename, or with the
original file? If the operation was to delete /tmp/junkfile, now renamed to
/goodstuff/best_ever, should we follow the dentry to the new name and delete it?
The point here is that an unusual event may have invalidated the user's preconditions
for the wanting to do the operation, and blindly retrying may not be the best course.
There may very well be better or more correct error codes to use than ENOENT in some
cases, but these would need to be examined on a case by case basis.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html