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. > Best regards, > Andreas Sebastian _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
