Manvendra Bhangui

I did this and I get this error argos:/usr/local/src/projects/spawn-filter/notqmail>git fetch remote: Enumerating objects: 17, done. remote: Counting objects: 100% (17/17), done. remote: Compressing objects: 100% (13/13), done. remote: Total 17...

OK. I changed it to https in .git/config and did a push. It has gone through git push --force Username for 'https://github.com': [email protected] Password for 'https://[email protected]@github.com': Enumerating objects: 16, done....

> If it is ok with you I would rebase the branch on the current master to reduce the complexity in git history. That would be awesome. I'm still struggling...

This will require some review and modification. I have this with me and uploading this as qmail-todo.txt instead of qmail-todo.9 [qmail-todo.txt](https://github.com/notqmail/notqmail/files/3390192/qmail-todo.txt)

Replying to old discussion, but thought I would mention something about compiling syncdir.c on RaspberryPI 64bit (with the latest headers) and on FreeBSD. 1. on the latest linux 64bit kernel...

I have tried something like this and ran out of limits on a busy system. We need to add a note on setting the limit in /etc/sysctl.conf. IIRC `fs.inotify.max_user_watches` was...

> A normal user may just get EMFILE when calling `inotify_init()`, but as qmail-send runs as root it is not affected by this. Yes, that could have been the reason....

> Shouldn't 1 watch be enough to look at the directory contents? Yes. You just need one `inotify_add_watch()` for a directory. But I think what happens is when an event...

read(2) could return `IN_Q_OVERFLOW`. I never had a read failure. What was failing for me was `inotify_add_watch()`. The inotify_add_watch was being called by around 5 devices. So it wasn't as...

Came across this while finding how one can run out of inotify resources. Apparently one setup a trace to find out who is using and consuming inotify(). https://unix.stackexchange.com/questions/15509/whos-consuming-my-inotify-resources