On November 8, 2015 9:06:51 AM EST, Sebastian Andrzej Siewior <[email protected]> wrote: >On 2015-10-26 21:49:03 [+0100], Andreas Cadhalpun wrote: >> Hi Sebastian, >Hi Andreas, > >> On 25.10.2015 21:58, Sebastian Andrzej Siewior wrote: >> >> I can't think of a good solution for this problem. >> > https://sourceware.org/bugzilla/show_bug.cgi?id=11460 > >This has been fixed in glibc 2.23. We have 2.21 in exp. > >> > But this is not helping. >> >> It's not helping yet, anyway. > >Maybe it is :) > >> > I haven't been looking at it but wouldn't it work to replace fts >with >> > ftw()? I mean have no idea what upstream plans to do but if it just >> > about browsing via a directory ftw() should be good enough :) >> >> Using ftw instead of fts might work. >> Currently fts seems to be only used in onas_ht_add_hierarchy. > >This code is new and I would call fast written. The error handling >is: > hnode = onas_hashnode_init(); > if (!hnode) return CL_EMEM; > >hardly existing since fts_close() wasn't called on that one. Or for >some >reason not abvious to me it is not required. > >That said I hacked up something that is half way done i.e. not complete >or tested. I used nftw() and a mutex() since the function passed to >nftw() can't have a private argument and I kind of need it for struct >onas_ht *ht. And after seeing that thing above I was thinking about >pulling in fts() from glibc to remain bug compatible with upstream. And >then I was thinking about stable + oldstable and the amount of >non-upstream >code we are pushing there I was thinking: > HEY! What about disabling FANOTIFY which disables this feature > and we don't have to worry about this and we enable it once > glibc 2.23 hits unstable? > >Any thoughts on this? We should react soon I think since we need to >pass >the new queue.
Glibc 2.21 will be in unstable soon at which point 2.22 will go to Experimental. I understand the release date for 2.23 is undetermined. Is the glibc change something that could be back ported? I would seriously like to avoid disabling fanotify , since that would be a regression and I know people use the feature. Scott K _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
