Amir Goldstein <amir73il@xxxxxxxxx>: > There are more error that you can get same way that you got > EOPENSTALE. The fact that I filtered EOPENSTALE is fixing a POSIX bug, > but it does not fix the general problem you described. > > For example, I know you can get ENODEV, because I got it on > out test env. This is the case of a "stale device node" - by the time > you get to read an access event generated on a device file, the device > that this file represents does not exists and cannot be opened. > > As with the case of EOPENSTALE, your app should just read again > when that happens. Thing is, I must treat every unknown error value as critical and exit. That's because the problem might be persistent and spinning in a read loop hangs the system. Unless, of course, the system call API explicitly declares all problems as transient and tells the application to retry indefinitely. ENODEV certainly doesn't have the ring of a transient error. I don't really see why read(2) on the fanotify fd should return any random errors. The fanotify fd is purely a software device and should only have a fixed, documented set of failure modes. The other file descriptor (metadata->fd) is tied to a real file and could fail in a million ways; that's understandable. Marko -- +358 44 990 4795 Skype: marko.rauhamaa_f-secure -- 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
