Building a recursive file system watcher in Linux

Leadwerks automatically monitors the current project directory, and will reload assets whenever the file changes. Implementing this functionality in Linux turned out to be easier than I expected, with the built-in iNotify API.

Following my previous update about correcting file path cases, I am now able to load all our maps in Leadwerks.  The power of this tool running natively on Linux is starting to show, if I do say so myself:

Posted Image

The next step is to implement a file system watcher to detect file changes.  Leadwerks automatically monitors the current project directory, and will reload assets whenever the file changes.  This allows you to keep an image open in an image editor like GIMP, and any time you save your changes will be reflected inside Leadwerks.  It's a great workflow for artists and just the kind of feature I wanted to bring to Linux with this project.

Linux has a built-in file system watcher class called "inotify".  Interestingly, this class was added to Linux in 2005, the same year the iPod was released, but there appears to be no connection. The "i" in "inotify" stands for "inode". Dennis Ritchie explains:

In truth, I don't know either. It was just a term that we started to use. "Index" is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the i-number is an index in this array, the i-node is the selected element of the array. (The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.)

The inotify system is pretty straightforward to implement, with a procedural C interface.  One thing that tripped me up was an odd layout of the inotify_event structure.  It actually has a char pointer built into the structure, so technically the structure does not have a determined length.  I don't believe I have ever encountered this design before, but I also am usually dealing with std::string classes.

One drawback of inotify is that it isn't recursive.  While searching for information on the design, I came across this post by Robert Love, one of the two guys who wrote it (the other being John McCutchan).  I disagree with his rational for omitting recursion; just because the performance is not as optimal as he would like does not mean the end user's tastes and preferences will change.  I can't imagine a scenario when you wouldn't want the system to work recursively, or at least have the option to.  In any case, implementing a recursive watch system was fairly easy.  The entire file watch system from zero to finished only took about half a day. So we can mark this as one of the features where I overestimated the time and complexity of implementation.

File creation, deletion, and modify events are now firing reliably so I am going to plug this code into the editor and start testing it out.  Because the editor already works reliably on other Windows and OSX, I don't anticipate any problems.  I do not have a firm release date yet, but as you can surmise, we are nearing completion of Leadwerks for Linux.

Latest Jobs

Xbox Game Studios

Redmond, Washington
Technical Lighting Artist


Hamburg, Germany
Game Designer - Elvenar

Six Foot

Houston, TX
Six Foot Director, Player Relations

Hometopia Inc.

Lead Engineer
More Jobs   


Explore the
Subscribe to
Follow us

Game Developer Job Board

Game Developer Newsletter


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more