1. 14 Dec, 2017 4 commits
  2. 13 Dec, 2017 2 commits
  3. 11 Dec, 2017 3 commits
  4. 10 Dec, 2017 1 commit
  5. 08 Dec, 2017 1 commit
  6. 07 Dec, 2017 2 commits
  7. 06 Dec, 2017 3 commits
  8. 05 Dec, 2017 2 commits
  9. 01 Dec, 2017 1 commit
  10. 29 Nov, 2017 2 commits
  11. 23 Nov, 2017 4 commits
  12. 22 Nov, 2017 3 commits
  13. 21 Nov, 2017 3 commits
  14. 20 Nov, 2017 1 commit
  15. 17 Nov, 2017 2 commits
  16. 15 Nov, 2017 2 commits
    • Julien Muchembled's avatar
      typo · 325af127
      Julien Muchembled authored
      325af127
    • Julien Muchembled's avatar
      Use inotify-simple instead of inotifyx · 31142ddf
      Julien Muchembled authored
      There's little hope that it gets maintained because it contains a C extension whereas alternatives often use ctypes. In particular, it has no support for Python 3, and this is a blocker for us. At the beginning, [I though we were switching to pyinotify](0bb405fc): it is quite popular, and even used by fail2ban, but the code is ugly (big, crazy API, limited, and probably slow).
      
      I didn't really know inotify and it's disappointing to see that created files (CREATE+WRITE+CLOSE_WRITE) can't be distinguished from hard links (CREATE). Acting upon new inodes is a common scenario and in the first case, you want to wait CLOSE_WRITE or you would read a partially written file. What I mean is that inotify is often unreliable, unless you detect changes done by your own software (e.g. you can make sure that files aren't hard-linked) but then some other IPC is probably simpler.
      
      In any case, I open this MR because I haven't tested it. I only checked with pylint (hence the second commit).
      
      /cc @alain.takoudjou @gabriel @luke (from Git history)
      
      /reviewed-on nexedi/slapos!257
      31142ddf
  17. 14 Nov, 2017 4 commits