Handle CHMOD only events in hugo server

[BernCarney]

Currently use a windows PC as my main machine with linux containers in docker as an, attempted, dev environment. Unfortunately with the lack of support for file change events between windows and linux, this has been a pain.

One work around that was promising was Docker-Windows-Volume-Watcher, but unfortunately, it doesn't work with the way Hugo Server handles file change events. Hugo server does not recognize chmod and touch events as file modifications (it sees them but ignores them) which the aforementioned tool uses as a workaround.

That is why I am proposing a flag that allows the hugo server to be run where chmod/touch events are not ignored (ie: hugo server --notify-all) until Windows or Docker comes up with a more permanent solution to the file sync issue between linux and windows.

I understand this is not a bug with Hugo but moreso with the underlying systems I am using which is why I have labeled it a feature request.

Issue for reference: Docker-Windows-Volume-Watcher Issue 4

[bep]

I have spent some time debugging this myself on various OSes, and I can feel your pain.

• In "normal cases" we see a mix of CHMOD, WRITE, CREATE, DELETE events.
• Hugo currently throws away the CHMOD events.
• If you say that your use case only triggers CHMOD, then we could apply some logic that said "if events contain only CHMOD", then update.
• Note that we have some partial logic that differentiates between WRITE etc. This CHMOD situtation should be functionally same as a DELETE followed by a CREATE.

[zimmski]

We are running into this problem. We decided to use Hugo for our new website and we are developing it inside a Vagrant VM. Alright, VirtualBox does not do events on synced-folders and we are using NFS so there is no chance of using inotify anyway. However, there are plugins such as https://github.com/adrienkohlbecker/vagrant-fsnotify that forward the events by executing commands inside the VM: "touch $file" and "touch $file && rm $file" in this case.

The problem is, Hugo does not do a rebuild on CHMOD. And I think it is because of this line https://github.com/gohugoio/hugo/blob/master/commands/hugo.go#L1087 (I am new to Hugo so please correct me if I am wrong). Would it be possible to simply add a flag to enable CHMOD again for users (like us) which have only the possibility of CHMOD events.

[bep]

Would it be possible to simply add a flag to enable CHMOD again for users (like us) which have only the possibility of CHMOD events.

I not a big fan of "adding a flag" to solve any problem.

A patch for this has to be a little more involved: Let CHMOD trigger rebuild only if it is not accompanied by other event types, and add some kind of throttle to limit rebuilds.

[zimmski]

Your two requirements sound like a major undertaking for something that is documented in the source code as a MacOS problem. Furthermore, when I look through my today's log of events I do not see any case where I could reproduce that problem. So I cannot implement your requirements, since there would be no way for me to test them.

I do not see any compatibility promises, so the flag could be removed later if the infrastructure has been set up for your requirements. In any case: removing the workaround for MacOS with this flag would simply broaden Hugo's user-base.

[moorereason]

@bep,
Can we make this OS X workaround of ignoring CHMOD events only applicable to OS X? It's not clear to me from the code comments if we ignore CHMOD solely because of OS X or if there's more to it than that.

if ev.Op&(fsnotify.Chmod|fsnotify.Write|fsnotify.Create) == fsnotify.Chmod && runtime.GOOS == "darwin" {
    continue
}

[bep]

Can we make this OS X workaround of ignoring CHMOD events only applicable to OS X?

It is an application problem. Lots of software "touches files" (antivirus etc.). Creating a monkey patch now will maybe solve 1 person's problem, but break others.

[saitho]

Creating a monkey patch now will maybe solve 1 person's problem, but break others.

Would it be possible to simply add a flag to enable CHMOD again for users (like us) which have only the possibility of CHMOD events.

I think a flag would be the best solution here... Wouldn't break existing installations as users would have to explicitly enable this feature. ;)