Opened 6 years ago

Closed 6 years ago

#14834 closed enhancement (fixed)

wxFileSystemWatcher: Add wxFSW_EVENT_UNMOUNT flag for inotify's IN_UNMOUNT

Reported by: dghart Owned by:
Priority: normal Milestone: 3.0.0
Component: base Version: stable-latest
Keywords: wxFileSystemWatcher wxFSW_EVENT_UNMOUNT Cc:
Blocked By: Blocking:
Patch: yes


Inotify emits an IN_UNMOUNT event when a watched item's filesystem is unmounted. wxFileSystemWatcher currently treats this event as an error; I'm not sure why. The attached patch (which should be applied after the IN_ATTRIB one but doesn't depend it) converts it to wxFSW_EVENT_UNMOUNT which I've added to the wxFSWFlags enum (using the IN_UNMOUNT value for no important reason). It shouldn't be included in wxFSW_EVENT_ALL as IN_UNMOUNT is not intended to be a user-requested watch and is outside the INOTIFY_ADD_WATCH bit-mask.

As unmounting is not entirely cross-platform, I've #if def.ed wxFSW_EVENT_UNMOUNT in common code. In the future, NOTE_REVOKE looks like the best kqueue match; this is currently ignored.

I can't think of a good way to add a test for this, but it can be seen to work in the fswatcher sample: mount something, watch a dir inside that filesystem, then unmount it.

Attachments (2)

unmount.diff download (4.7 KB) - added by dghart 6 years ago.
errors.diff download (1.6 KB) - added by dghart 6 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 6 years ago by vadz

  • Milestone changed from 2.9.5 to 3.0

I wonder how does this work under Windows and OS X right now. I.e. if the directory is unmounted (or a disk is ejected under Windows), do we get an error or nothing at all? If it's the latter, then this patch is fine (nitpick: just need "@since 2.9.5" in the docs), but if this results in errors under the other platforms then giving an error under Linux doesn't seem like such a bad idea.

Would it be possible for you to test how does this behave there please?

Changed 6 years ago by dghart

Changed 6 years ago by dghart

comment:2 Changed 6 years ago by dghart

I have no way of testing OS X. The code contains nflags &= ~NOTE_REVOKE, so I suspect it does nothing.

On ejecting a CD in winXP, wxIOCPThread::ProcessNativeEvents received no event of any sort. (It's possible that being in a virtualbox guest affected this, but XP itself did notice the CD and its removal.)

I've also now tested without the patch in wxGTK and found the errors/warnings code is broken. Prior to the r72961 change, it failed as GetErrorDescription() called Watcher2NativeFlags() and got back IN_ALL_EVENTS. This isn't in the list of known errors, so GetErrorDescription() asserted. Later GetFSWEventChangeTypeName() asserted too as it doesn't handle wxFSW_EVENT_WARNING or wxFSW_EVENT_ERROR. Since r72961 there are similar problems. These are fixed in errors.diff, which is needed whatever the IN_UNMOUNT decision.

I've redone unmount.diff to apply over errors.diff, and also fixed the doc.

comment:3 Changed 6 years ago by VZ

(In [72986]) Convert wxFSW_EVENT_{WARNING,ERROR} to string correctly.

Previously these types were not handled at all, resulting in asserts.

See #14834.

comment:4 Changed 6 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [72987]) Add wxFSW_EVENT_UNMOUNT wxFileSystemWatcher flag and implement it for Linux.

This flag generates the corresponding event when the file system containing
the watched directory is unmounted. Currently it is only implemented for
Linux where unmounting now generates this event instead of an error.

Closes #14834.

Note: See TracTickets for help on using tickets.