No inotify events from TC Linux?

[MikeLockmoore]

Hello.  I'm working on developing an FLTK-native file manager.  I thought I could use the inotify API (http://linux.die.net/man/7/inotify) to provide feedback to my app whenever directory contents change, so I can automatically update the display. 

I tried it, and the API calls all seem to succeed, but I don't get any inotify events after creating or deleting files.  I set up the inotify watch on a particular directory (the dir file itself, not each of the contained files) and included watch options like IN_MODIFY.  I admit to just learning about this API, so it's possible I am still doing something wrong, but I wonder if TC's kernel is set up to provide inotify filesystem monitoring?

If not, it's not a big deal.  I can write my own monitoring routine, but mine will probably consume more CPU and be a little bit less power-friendly.  If any of the Core team knows about this API or how kernel config options affect it, I would appreciate hearing about it.  Thanks!
--
Mike Lockmoore

[curaga]

CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

It's also worked fine for me and Robert (the daemon for TC < 2.7). Checking the man page:

IN_CREATE         File/directory  created in watched directory (*).
           IN_DELETE         File/directory  deleted  from  watched  directory
                             (*).

Looks like you would need those too.

[MikeLockmoore]

@curaga: Thanks for replying.  EDIT: OK, that looks like the stock TC kernel should be configured for inotify.  The current kernel does not require a separate daemon running for other apps to receive the inotify events, does it?

When I tried the inotify API in my file manager C-program, I repeatedly checked for pending IO with an ioctl() call, and never saw any pending inotify info, even after deleting and creating files in the watched directory (and the parent directories, all the way up to /). Then, just for testing, I added  a blocking read() call on the file descriptor returned by the inotify initialize function.  That continued to block even after I deleted and created files in an external shell process. It's acting like either it's not really watching what I intended, or it is, but the kernel isn't providing the event info to the inotify API special file.

I'd like my app to work directly with TC Base.  Perhaps if my app needs a separate daemon inotify daemon running, it could be made a dependency if it not too big and difficult to manage.  Are either the libnotify or flnotify extensions related to this inotify stuff?
--
Mike L

[roberts]

I found that I had not posted the source to tce-notify, a small utility that I wrote for Tiny Core 2.7.

In TC/MC prior to v2.7, (2.0 - 2.6.1), a support extension, tce-notify, will be required. It should be loaded first, as only extensions loaded after it can benefit from its handling. This is a stopgap measure; upgrading to v2.7 is strongly recommended. tce-notify is a daemon which runs both ldconfig and depmod for every extension, so using it will put additional load on the system compared to the previous behavior.

Perhaps you will find the source useful:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tce/src/tce-notify.c

[curaga]

Hm, I forgot tce-notify was using DNOTIFY and not INOTIFY. Attaching some sample code I made a year ago, it works ok on TC 3.

[MikeLockmoore]

@curaga, roberts:  Thanks for the code samples.  I will review and see if I can use these techniques in my app.

[MikeLockmoore]

@curaga: 

... IN_CREATE ... IN_DELETE... Looks like you would need those too.

Yes, you are absolutely correct.  I wrongly assumed that any file creation and deletion operations would trigger a MODIFY event on the parent directory, but it appears that inotify does not work this way.  Adding the IN_CREATE and IN_DELETE flags on the watch request makes it work as I expect.  My full watch mask includes:

Code: [Select]

IN_ATTRIB | IN_MODIFY | IN_CREATE | IN_DELETE | IN_DELETE_SELF | IN_MOVE_SELF | IN_MOVE_TO | IN_MOVE_FROM | IN_MOVE_TO
Now in my app I just need to keep to keep the following things synchronized:
1) The actual filesystem state
2) The internal representation of a filesystem (which is normally a subset of #1)
3) The GUI presentation of the filesystem (which is normally a view of a subset of #2)

 

[curaga]

Your mask has IN_MOVE_TO twice

[MikeLockmoore]

@curaga: Copy+Paste error!   

I have my app responding to external filesystem changes now using inotify.  At first, I tried to by fancy and keep removing and adding (or re-adding) inotify watches on only the currently-expanded parts of the directory tree (the parts you could see in the GUI).  But in this case, the inotify event info seemed to always refer back to a previous instance of a watch.  For example, at some point I have /tmp being watched.  Then the user changes something in the directory tree, so my app would use the inotify "remove watch" API call, then add it back again, which provided a new "watch descriptor".  However, when an external directory change happened, my app would get an event notification with the previous (removed!  ) watch descriptor number. This was kind of inconvenient, since my code could no longer match this event to part of the filesystem.  I wonder if this is a kernel bug.  It seems kind of broken.    Or perhaps I need to know how to flush any pending watch changes more immediately.

As a compromise, I don't remove watches now for the directories that are collapsed (i.e. no longer visible), and don't re-add ones already added.  So my app gets a few more potential updates than I need given the visible content, but that not too bad.  Hopefully, the total number of watches has a reasonable limit that most users won't hit.
--
Mike L.