Despite disabling the SFV checksum checking LinuxDC++ does it anyway.

Said option only affects incoming downloads. If .sfv file exists it will be checked when the files are shared. If the calculated checksum doesn't match the value in the file, it is not shared. Now when you restart LinuxDC++ it will check the share for new files, it will see the files with wrong checksum as new (as those were not shared previously) and calculates the tth and checksum again (which will most likely fail again).

--RZ

Hello RZ, thank you for your quick answer,
straight to the point:

bug or feature?

best regards
myrcek

On Mon, Feb 2, 2009 at 9:04 PM, Razzloss
<email address hidden> wrote:
> Your question #59645 on LinuxDC++ changed:
> https://answers.launchpad.net/linuxdcpp/+question/59645
>
> Status: Open => Answered
>
> Razzloss proposed the following answer:
> Said option only affects incoming downloads. If .sfv file exists it will
> be checked when the files are shared. If the calculated checksum doesn't
> match the value in the file, it is not shared. Now when you restart
> LinuxDC++ it will check the share for new files, it will see the files
> with wrong checksum as new (as those were not shared previously) and
> calculates the tth and checksum again (which will most likely fail
> again).
>
> --RZ
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/linuxdcpp/+question/59645/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/linuxdcpp/+question/59645
>
> You received this question notification because you are a direct
> subscriber of the question.
>

The inability to disable SFV-checking for shared files is a feature. It's bug only in that case if the files really are ok (if some other sfv-verification software passes and linuxDC++ fails (or it's a bug in that other software))

--RZ

I think this is a legitimate concern. The option says "Enable automatic SFV checking", it doesn't specify that this applies only to downloading but not to hashing. The option description should be changed to be more specific or it should use the setting when hashing. I don't see any harm in disabling SFV checking during hashing if the user requests it. There are scenarios where the user may update the file or move a similarly named file into that folder where the file is still valid, it just doesn't match the original crc32. For example, if a user updates the ID3 tags of a MP3 the crc32 will change but the user still expects the file to be shared since it is a valid file. Of course they should probably delete the entry from the SFV or the entire SFV itself in thise case, but who are we to tell the users what to do with their files. Razzloss, thoughts?

AFAIC, SFV checking should be left alone. Users shouldn't be messing around with their scene downloads. If they want to change id3 tags or whatever and still share them to their unaware pals, let them remove the SFV file.

I kind of go with individ here. If release has an .sfv it should be used to prevent intentional (ID3-tags) and unintentional (hardware failure) messing of files.

But the option name/description should be better as the current one causes too much confusion. (or remove the option completely after the merge https://bugs.launchpad.net/dcplusplus/+bug/242172 if that is still the case)

--RZ