Windows support?

[blaggacao]

Are there any plans to support Windos's FileSystemWatch API?

I found a reasonably advanced mapper to the inotify command here:
https://github.com/thekid/inotify-win/

however, it lacks still some fundamental support for more complex operations, such as moving:
thekid/inotify-win#7

[emcrisostomo]

Hi @blaggacao,

I'm acquainted with that Windows API. Creating a monitor for it wouldn't be difficult, but I'm essentially lacking time for doing that.

I'm following up on the referenced issue.

[v3n]

Hey @emcrisostomo, I'm interested in this feature as well and noticed some progress being made in a feature branch. Is there any help you might need with it?

[emcrisostomo]

Hi @v3n,

yes, you're right. The code in the branch feature/windows-support contains a functional, alpha-quality monitor that uses the Windows API. It's functional and it would be cool if you could try it and report bugs.

The Windows API let us watch directories, not files. Currently, the Windows monitor is subject to this limitation: fswatch will skip files specified in its arguments (you can see diagnostic output using the -v option) and will only watch directories. Also, once you watch a directory, the Windows API will report events for children at any depth: that means that fswatch will report events for a directory and recursively for all of its children even if you don't specify the -r option.

Finally, you need CygWin to be able to compile this program and the command line arguments are parsed as if they were UNIX file paths. This dependency might be removed in the future.

Let me know if you try it.

[v3n]

@emcrisostomo,

That's great news. Currently my dependency stack doesn't include cygwin, and I'd like to avoid including it. I'm going to attempt to build it without it (I'm using bkaradzic/genie for our pre-build system). I'll report on the progress. Would there be any interest in a PR for the build script if I'm successful?

Also, files are ignored, is this a libfswatch or a fswatch feature? Is the library smart enough to redirect file watch requests to the directory or do I need to code that path manually?

Thanks!

[emcrisostomo]

Hi @v3n,

Yes, thanks, send a PR if you please. CygWin is used to convert UNIX paths to Windows paths. It should be very easy to remove it. However, since CygWin is widely used and fswatch strives for portability, I like the idea of its being able to use UNIX paths as well. CygWin should be made an optional component and fswatch should be able to understand whether a path is a UNIX path or a Windows path.

All the functionality is contained into libfswatch: fswatch jusr parses command line arguments and the sets up a monitor using libfswatch.

Watching the parent directory of a file is trivial: it's not in the code, though. There are some nuances to consider. Here is the first that come into my mind: we should detect whether the user specifies a file that gets watched because it belongs in a subtree rooted at another watched file's parent. The Windows API would report the same event multiple times in this case.

[blaggacao]

great news! 👍

[v3n]

@emcrisostomo, it's my understanding that Windows API calls understand Unix paths natively, so that shouldn't be a huge issue. However, I'm sure my testing will reveal whether that's the case or not.

I'll start the integration in the next couple of days.

[emcrisostomo]

Hi @v3n,

No, that's not true. Many Windows APIs understand paths that use the slash (/) as path separator, but it's not possible to do so when using UNC paths (which is the only way Windows lets us specify a Unicode string as a path or a path longer than MAX_PATH).

Furthermore, UNIX paths don't know anything about what a drive is.

The current version of libfswatch in the develop branch assumes paths are CygWin's UNIX paths and converts them to and from the Windows representation using the CygWin library. For portability's sake, I believe fswatch should have the option of using UNIX paths, since I expect many users (including myself), to use it with existing UNIX shell scripts.

Now, I'm thinking about making the CygWin dependency optional and adding an option to activate the interpretation of Windows paths, both as arguments and as output.

[v3n]

@emcrisostomo Ah, I see. I've never dealt with UNC paths, that would explain why I didn't know the difference.

The strategy you mentioned seems like a good one.

[v3n]

I've checked in an initial version of the GENie file over here while I'm working on the FSWatch integration: https://github.com/v3n/altertum/blob/feature/fswatch/genie/fswatch.lua

So far it compiles with fine with GENie under OS X. Haven't tested Windows yet, will try to get to that when I get home today. I'm sure I've probably missed a few flags while converting the autotools files. Also haven't tested the run-time, gettext is the only thing I'm concerned about, but it seems like you guarded it with preprocessor macros nicely.

Some things I noticed:

• Would really love a compile-time flag to disable exceptions-noticed some comments about C-friendly error handling.
• poll_monitor is not compatible on Windows without Cygwin.

[emcrisostomo]

Cool.

A couple of things:

• The FSEvents monitor is not available on BSD systems, just on OS X.

configuration { "osx or bsd" }
  defines { "HAVE_STRUCT_STAT_ST_MTIMESPEC" }
  files { LIBFSWATCH_SRC_DIR .. "c++/fsevents_monitor.cpp" }

• The kqueue monitor may be available on BSD systems but not on Linux:

configuration { "linux" }
  defines { "HAVE_STRUCT_STAT_ST_MTIME" }
  files
  {
    LIBFSWATCH_SRC_DIR .. "c++/kqueue_monitor.cpp",
    LIBFSWATCH_SRC_DIR .. "c++/inotify_monitor.cpp"
  }

• Yes, you're right: the poll monitor is a stat()-based monitor that needs a bunch of POSIX functions.
• Callers of the C API should not receive exceptions: if it happens, it's a bug. There are comments in the code because I should review it. Said this: what do you mean exactly with a flag to disable exceptions?

Just out of curiosity, which is the advantage of building fswatch and libfswatch using GENie?

[v3n]

re: GENie;

• Power; similar to a lighter version of CMake, trades some bloat for the ability to script in Lua.
• Convenience; like CMake, integrates nicely into other build systems without lots of work–i.e. generates Make/Xcode/VS/etc files that you can just drop into your existing files if needed.
• Flexibility; can be a full-stack build generation tool if needed, or just generate a single Makefile that your hand-written make calls.
• Cross-platform; isn't reliant on POSIX or Windows-only tools.
• Not super-relevant for this project but relevant to my own interests, it natively supports generating project files for Xbox/PS3/PS4 deployment.

As for CMake vs. GENie, that's just a personal preference. I'm more than happy to offer my build files for GENie if you want them, but won't be offended if you want to go another route (or even just stay with auto tools) as I do recognize that CMake seems to be the defacto standard. My only real concern is being able to build natively on all platforms without a ton of Cygwin/MinGW workarounds. 👍

Thanks for the pointers on the build file...my brain definitely wasn't work when I wrote some of that.

re: Exceptions; clean compile with -fno-exceptions. Now that I know about the C API though, I might just interface to that to avoid exceptions (paradigm we attempt to avoid in game engines).

[emcrisostomo]

Thanks for your explanation about GENie, @v3n. I'll definitely have a look at your build files: it's always nice to learn new things.

You're welcome, I guess it's normal you haven't tried your build files yet on all those platforms.

About exceptions: yes, I understand your concerns. I'll quickly review the C API tomorrow. I use the C++ one and wrote the C wrapper as a courtesy: but I know that it requires at least a review (that's why those comments you mentioned exist in the first place). I'll try to do that tomorrow. By the way, exceptions are not used for flow control, though, and you should not get any of them during normal usage.

[emcrisostomo]

Solved in 1.6.0.