On 04/17/2013 06:39 AM, Bernhard Voelker wrote: > On 04/04/2013 03:42 AM, Pádraig Brady wrote: >> I've nothing against simplicity though since the >> inotify code already deals with missing files when >> following by name, by watching the parent dir, >> it might be easy to adjust to handle this case. > > Hi Padraig, > > sorry for the late reply.
Thanks for the update. Will review ASAP. > After all, I think tail.c is not in a very good, maintainable shape. > There are so many knobs, partially with overlapping meaning like > 'follow_mode' vs. 'forever', or 'reopen_inaccessible_files' vs. > f[i].ignore etc., that it's rather hard to do the right change > without breaking something else. > WDYT? I agree that the current inotify functionality isn't ideal. inotify advantages immediate output of changes (but one can always use -s.1) could be used to watch *.log in a local directory (but we don't currently leverage inotify to provide this functionality) inotify disadvantages not used for stdin can't be used for remote files doesn't work for remounts only works on linux more complicated Also in the meantime the more encompassing fanotify Linux API has become available which might simplify implementation and/or provide new functionality. At this stage I wouldn't be on for removing the current inotify implementation, but also I wouldn't be enthused about adding any large refactoring or new functionality based on it. Any large changes (like supporting watching any new files in a dir for e.g.) should probably consider using fanotify or some other mechanism instead. thanks, Pádraig.
