Miklos Szeredi <miklos@xxxxxxxxxx>: > I'm looking at the EOPENSTALE story and it very much looks like we can > just replace the single use with ESTALE and handle the lookup retry > logic nuances inside the lookup code... The fanotify problem is not simply a matter of choosing a POSIX name for an error. The question is, what problems should an fanotify application be prepared to handle and what should it do about them? Since a misbehaving fanotify application is likely to hang the entire operating system, it needs very clear guidelines for correct behavior. In particular, when the application does a read(2) on an fanotify file descriptor and gets back an error code, how is the application to recover gracefully and safely? Amir's patch shields the fanotify application from EOPENSTALE. I would very much like an extensive list of errors that read(2) on a fanotify fd can return. As it stands, I'm only aware of EAGAIN in the nonblocking case and EINTR in the blocking case -- and even those haven't been explicitly documented. Marko -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
