[Pkg-clamav-devel] Uploading 0.98.7+dfsg-4

[Sebastian Andrzej Siewior]

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