hashcheck is not available

[youk]

I just found out that hashcheck from pyrocore is not present in pyrosimple. Now I am wondering whether this omission is intentional.

[kannibalox]

Yep it was intentionally removed, since lstor --check-data <path> now does the same thing: https://kannibalox.github.io/pyrosimple/migrate/#hashcheck

[youk]

Alright, got it. Thanks.

[youk]

Is it so that there is no flag to suppress output (in case only exit code is needed)?

[kannibalox]

Is it so that there is no flag to suppress output (in case only exit code is needed)?

Try this on the latest code: lstor -o '' -q --check-data <path>. That will disable the progress bar and output no information about the torrent.

[youk]

This helps, thanks. Still it looks more like a workaround? Does it suppress all potential error messages (in addition to "Field '' not found")?

[kannibalox]

That will surpress all non-fatal messages, so it's still possible to get output. If you really want to discard absolutely all output, shell constructs are probably the best option: lstor <stuff> 2>&1 >/dev/null

[youk]

TBH, I don't find the current behavior intuitive and convenient. Consider two use cases:

1. Checking the hash in interactive shell. Since it is interactive shell, I would expect a quick indication of the mismatch. Let's suppose I am not interested in all those "WARNING:pyrosimple.scripts.lstor.MetafileLister:Piece #0: Hashes differ in file" messages, only in yes/no. In addition to the warnings, lstor -q -c suppresses the error message too. I have to check the exit code to realize there was an error.
2. Checking the hash in script. It is natural to check for error codes in scripts, but clear and concise error messages are important too. Currently I would have to parse stderr searching for ERROR:pyrosimple.scripts.lstor.MetafileLister (or examine traceback which is not much better) to get to the error message. I can't claim the following is the standard or conventional behavior for command-line utilities, but most commands or binaries I can think of behave like that: return the error code and print the error message.

BTW, the mention of -H on https://kannibalox.github.io/pyrosimple/usage-tor/#lstor seems invalid/obsolete:

lstor can also hash check the torrent against real data by using the -H flag.

[kannibalox]

Hm, fair points on all accounts. Not stopping the hash check on the first failure was definitely a holdover, and most of the things you mentioned have been fixed, however -q will continue to suppress non-fatal error messages.

BTW, the mention of -H on https://kannibalox.github.io/pyrosimple/usage-tor/#lstor seems invalid/obsolete:

Thanks, fixed as well, I would've liked to have used -H, but chtor was already using it for adding fast-resume information.

[youk]

Thank you for quick adjustments. Appreciate this. I have a few more remarks/suggestions.

1. If lstor -c is supposed to be a replacement for hashcheck, then unconditional printing of torrent attributes seems excessive. I surely assume that the main function of lstor -c is to do the hash check. On the other hand, it might be that -c means "in addition to listing torrent attributes, check the hash". If the former, I'd put listing attributes under a flag (-v if it makes sense) and only show the progress bar. If the latter, then the current behavior is reasonable.
2. I can see use cases when complete hash check is required, i.e. the ability to see all invalid pieces/files. Could you consider implementing this (in fact that would be the previous behavior)? Obviously, under some flag, so that there will be two modes: fail-fast and complete.
3. There is some inconsistency in how -q flag works when checking hash. -q is meant to "silence warnings", but it suppresses the progress bar too.

[kannibalox]

1. The -o flag now effects all outputs, and can be set to -o "" to disable any field output. This should make both cases work.
2. Can you explain an example use case for me? It's not too difficult to do, but would complicate error handling a little bit.
3. I've already waffled on this a couple times so I'm not keen to do it again, but I've added a --progress flag to lstor to allow forcing it on/off.

[youk]

2. Consider the case of an incomplete or corrupt multi-file torrent which can't be re-downloaded (dead or too large). Some files might be available elsewhere, so it is essential to know which ones fail the check.