All inotify filesystem events are chmod/attribute events

[vansante]

Description

As reported here by @ploxiln colima only seems to forward ATTRIB events, even when actually modifying files.

See this log:

root@843c34dbbfff:/container# inotifywait -m .
Setting up watches.
Watches established.
./ ATTRIB main.go
./ ATTRIB main.go

I have a file watcher utility that ignores these and only recompiles on modify events, so it would be nice if this could be addressed.

Version

colima version && limactl --version && qemu-img --version
colima version 0.8.1
git commit: 96598cc5b64e5e9e1e64891642b91edc8ac49d16

runtime: docker
arch: aarch64
client: v27.4.1
server: v27.4.0
limactl version 1.0.3
zsh: command not found: qemu-img

(I do not use qemu but vz and rosetta)

Operating System

• macOS Intel <= 13 (Ventura)
• macOS Intel >= 14 (Sonoma)
• Apple Silicon <= 13 (Ventura)
• Apple Silicon >= 14 (Sonoma)
• Linux

Output of colima status

colima status
INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/pvansanten/.colima/default/docker.sock

Reproduction Steps

1. Start a container with inotify-tools installed and a mount from the host machine
2. Exec into the container and run inotifywait -m -r .
3. On the host machine go to the mounted directory and run: touch test && echo hello >> test
4. Notice the events from the inotifywait command:

inotifywait -m -r .
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
./ ATTRIB test

Expected behaviour

I expect the container inotifywait command to issue 2 events:

• A creation event for the file
• A modification event for the file

I do not expect an attribute event

Additional context

No response

[redecs]

I'm considering switching to Colima and encountered the same issue with ATTRIB/CHMOD in environment like the one described above.

[vansante]

After taking a peek at the code, I see that we are replicating the events by doing a chmod call in the VM OS:

https://github.com/abiosoft/colima/blob/main/daemon/process/inotify/events.go#L104

Maybe it would work better if we instead used this command instead?

echo "" >> {filepath}

Which triggers the following events on my local machine:

inotifywait -m .
./ OPEN file.txt
./ MODIFY file.txt
./ CLOSE_WRITE,CLOSE file.txt

Of course it makes sense to do something similar written in native go, like issuing a file.Write() with an empty byte buffer.

[abiosoft]

This was actually a delibrate compromise.

If you look through the linked thread, you would notice that multiple attempts were made before resorting to this approach, which seems to work best for most users.

[vansante]

I see, but I think the main alternative that was discussed was the touch <filepath> strategy. What about opening the (abort if not exists), write zero bytes and closing the file again?

[redecs]

@abiosoft Thanks for clarification. I understand the deliberate compromise made here but I'm wondering if you would be open to having something like @vansante described earlier under a different configuration flag (maybe do the empty space append on files matching a glob pattern). Something like this might break some workflows but also it would enable others, so maybe it's worth having it with the clear mention of the pitfalls (experimental options after all).
My thinking around this is as follows: the proper solution here is hard to implement (example: custom fs / mount type like Docker has in their closed source for Docker Desktop) and that will take time (and most like needs to come upstream of Colima, maybe even Lima). I would rather have choice to enable an experimental flag that will enable a wider range of file monitoring tools to work.

Also thank your for Colima! I'm actually excited to use it to replace Docker Desktop after I figure out some quirks related to my work.

[abiosoft]

I know the thread is very noisy, but I think you can follow it a bit from here #261 (comment).

I am not sure how quickly I would get to this, but yeah I can introduce a config/flag that would write empty bytes.

Like it was mentioned in the thread, the issue with this approach is that some editors get confused and give a poor user experience by indicating that the file has been modified externally.

[redecs]

@abiosoft Thanks for the additional details. The external modification in editors is tricky to handle indeed, since a lot (most?) editors used today will complain about that. I'll try to build a PoC and see how that fares.