entr and improper inotify events

[Folo23]

• Microsoft Windows [Version 10.0.16278.1000]

entr is a small, unix-y utility that runs programs in response to changes in files.

Behavior of entr

While entr is notified when a change is made to a file from a Linux program within WSL, it isn't when the change is made from Windows.

For example, if I run entr on a small file, test.txt: $ echo "test.txt" | entr -p echo "changed", then open the file in Notepad, make some changes, and save it, nothing happens. If I open the same file in Vim in another WSL bash terminal, "changed" will be printed several times.

$ echo "test.txt" | entr -p echo "changed"
changed
changed
changed
changed

It also seems that entr doesn't pick up text appended to a file. If in the other terminal I append to the file: $ echo "Test String." >> test.txt. Nothing happens either.

Output of inotifywait

If I run inotifywait -m test.txt and then in another terminal echo "Test String." >> test.txt, the following output appears below inotifywait:

$ inotifywait -m test.txt
Setting up watches.
Watches established.
test.txt MODIFY
test.txt ATTRIB

Performing the same test on Linux shows the expected behavior:

$ inotifywait -m test.txt
Setting up watches.
Watches established.
test.txt OPEN
test.txt MODIFY
test.txt CLOSE_WRITE,CLOSE

Opening a file in Notepad and saving several changes reveals the following:

$ inotifywait -m test.txt
Setting up watches.
Watches established.
test.txt MODIFY
test.txt ATTRIB
test.txt MODIFY
test.txt ATTRIB
test.txt MODIFY
test.txt ATTRIB
test.txt MODIFY
test.txt ATTRIB

Making changes to a file in Linux that inotifywait is monitoring reveals the following:

~ inotifywait -m test.txt
Setting up watches.
Watches established.
test.txt MOVE_SELF
test.txt ATTRIB
test.txt DELETE_SELF

Tentative Conclusion

It seems like WSL isn't sending the proper inotify events when changes happen to a file, like indicating that a file has been closed. This causes programs like entr to fail.

[therealkenc]

From #216 (message): [edit- better link and quote]

One thing to note about Phase 2 regarding inotify for DriveFs files changed from Windows is that we are relying on an internal API similar to the user-mode ReadDirectoryChangesW, so we cannot return all 12 Linux inotify events. Events such as IN_OPEN and IN_ACCESS will never be reported, since NT cannot return the equivalent events.

[eradman]

The Build 14926 release notes seem to indicate that that IN_CLOSE_WRITE and IN_MOVE_SELF were implemented, but the examples that @Folo23 posted show that this is not the case.

What is the current list of supported events?

[therealkenc]

The release notes for 14926 say "Inotify support for files modified through WSL". In Folo's post, the files were not modified though WSL; they were modified with notepad.exe. You can glean what notifications are supported from ReadDirectoryChangesW. Notice the absence of a close event, for example.

That said, regarding the statement from the devs: "...NT cannot return the equivalent events"

[eradman]

@therealkenc, thanks for pointing out that this is not WSL.

Not having a close event is a problem, for this this application that still might be okay if there was a mapping from. NOTIFY_CHANGE_FILE_NAME from MOVE_SELF since editors nearly always write a temporary file and then swap it in to make the save operation atomic.

[poizan42]

@therealkenc Seeing that a filesystem filter driver can receive IRP_MJ_CLOSE I would say that there is no inherent limitations that prevents this from being implemented.

[therealkenc]

filesystem filter driver can receive IRP_MJ_CLOSE

Indeed. But you would have to convince the user of NOTEPAD.EXE to be operating on that filesystem filter driver, not NTFS on C:\. Which, I think is exactly what they have their top men looking at.

For now it appears, based on incomplete information, that they are limited to Zw* etc calls, just like the rest of us. You see this in the WSL networking stuff too. They don't have their own net filter driver either. They are limited to whatever WSK gives them.

Nothing prevents anything from being implemented, natch. They p0wn ring zero. Hence the Archer quote.

[benhillis]

Closing out old issues, if you're still having issues on newer versions of Windows please open a new issue.

[therealkenc]

The OP ask was addressed in WSL2 (by way of ext4). The entr application (a small, unix-y utility that runs programs in response to changes in files) will be fine there. For 9p (aka /mnt/c) the new landing zone is #4739.

[CervEdin]

@therealkenc but not on NTFS filesystems?