Re: inotify_rm_watch() user-space safety requirements?

2014-05-30 Thread Michael Kerrisk (man-pages)
Hi Heinrich, On 05/27/2014 09:32 PM, Heinrich Schuchardt wrote: > On 27.05.2014 19:25, Jeff Smith wrote: >> inotify's behavior concerning events from removed watches (they do >> happen) and watch descriptor reuse (beyond my knowledge) is currently >> undocumented. >> >> Although it mimics a

Re: inotify_rm_watch() user-space safety requirements?

2014-05-30 Thread Michael Kerrisk (man-pages)
Hi Heinrich, On 05/27/2014 09:32 PM, Heinrich Schuchardt wrote: On 27.05.2014 19:25, Jeff Smith wrote: inotify's behavior concerning events from removed watches (they do happen) and watch descriptor reuse (beyond my knowledge) is currently undocumented. Although it mimics a standard

Re: inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Jeff Smith
Hi Heinrich, Thanks for looking into this. I've never encountered the aliasing via wraparound or otherwise, but I've tried to code against unexpected descriptor reuse anyway through more flexible workarounds. From a user standpoint, denser descriptor reassignment would be preferable to facilitate

Re: inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Heinrich Schuchardt
On 27.05.2014 19:25, Jeff Smith wrote: inotify's behavior concerning events from removed watches (they do happen) and watch descriptor reuse (beyond my knowledge) is currently undocumented. Although it mimics a standard multiplexing interface in most regards, writing a robust user-space handler

inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Jeff Smith
inotify's behavior concerning events from removed watches (they do happen) and watch descriptor reuse (beyond my knowledge) is currently undocumented. Although it mimics a standard multiplexing interface in most regards, writing a robust user-space handler is comparatively more complex due to the

inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Jeff Smith
inotify's behavior concerning events from removed watches (they do happen) and watch descriptor reuse (beyond my knowledge) is currently undocumented. Although it mimics a standard multiplexing interface in most regards, writing a robust user-space handler is comparatively more complex due to the

Re: inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Heinrich Schuchardt
On 27.05.2014 19:25, Jeff Smith wrote: inotify's behavior concerning events from removed watches (they do happen) and watch descriptor reuse (beyond my knowledge) is currently undocumented. Although it mimics a standard multiplexing interface in most regards, writing a robust user-space handler

Re: inotify_rm_watch() user-space safety requirements?

2014-05-27 Thread Jeff Smith
Hi Heinrich, Thanks for looking into this. I've never encountered the aliasing via wraparound or otherwise, but I've tried to code against unexpected descriptor reuse anyway through more flexible workarounds. From a user standpoint, denser descriptor reassignment would be preferable to facilitate