SFV checker file name bug

[valdikss]

SFV checker code contains a bug: the file name inside SFV file is searched by substring and no check for end of line is performed.

Example:
The folder with the following files:

the.fp.2011.limited.1080p.bluray.x264-psychd.sub
the.fp.2011.limited.1080p.bluray.x264-psychd.subs.sfv

SFV file contains:

the.fp.2011.limited.1080p.bluray.x264-psychd.subs.rar 18239c0b

Expected result:
No CRC32 record for "the.fp.2011.limited.1080p.bluray.x264-psychd.sub" is found inside SFV file.

Actual result:
dcpp/SFVReader.cpp SFVReader::tryFile opens SFV file, finds "the.fp.2011.limited.1080p.bluray.x264-psychd.sub" substring and tries to convert hex string of "s.rar 18" (instead of "18239c0b") to hex value with sscanf.
the.fp.2011.limited.1080p.bluray.x264-psychd.sub is not added to share because of incorrect CRC32.

[eMTee (realprogger)]

There were numerous reports over the years of files being left out of share in situations similar to what's described here and this seems to be the most probable reason of those "randomly" skipped files in folders containing an .sfv file.
Thanks for taking care of reporting it.

[valdikss (valdikss1)]

Should I make a code fix and send a patch, or will you fix it yourself? EiskaltDC++ is waiting for upstream code fix in DC++.

[eMTee (realprogger)]

You're always welcome to create a patch. I think these days that'd be the fastest solution for yourself especially if you still keep using DC++ code as upstream.

[eMTee (realprogger)]

Fixed in DC++ 0.870.