Always verify local data after torrent finishes.
Always verify local data after torrent finishes.
I've had a few torrents lately that have been corrupted. Usually just one .rar file in many that fails a crc check. I go back to transmission, 'verify local data' manually and it fixes the file. This has happened with two different harddrives and with at least one other torrent program, qBittorrent, so I don't think it's necessarily hardware or software related. Could transmission have an option to force verification after a torrent is completed?
Re: Always verify local data after torrent finishes.
It's just my two bits. Not that I am against a feature, though don't you think it's redundant ?
I think torrent protocol forces a hash check on every piece as it is downloaded, if it is not in the protocol itself any sane client do so. You'd like to run it again after getting the whole file.
Your situation is strange, cause it means your data got corrupted in the mean time or the client is not working well falsely thinking the piece in question is ok; which in fact is not the case since a manual check caught it.
I would advise you to really watch for your data. I am not an expert but I am really sure that when a torrent client gets a piece it calculates and checks its hash. I am as close as possible to be sure data your data somehow gets corrupted and verifying everything a second time should be seen as a valid solution. You really need to remove the cause mate, as it sound pretty dangerous to your files.
Well there is another possibility. The torrent client really screws the data itself somehow but I think it is less likely and you yourself said that you had checked two clients. Either way second check is not a proper solution. For you it better if the torrent clients were bugged. It would mean rest of your files are safe from this. If not it is the hardware most probably (not necessarily HDD) or the operating system or whatever utility that can get to your files.
I think torrent protocol forces a hash check on every piece as it is downloaded, if it is not in the protocol itself any sane client do so. You'd like to run it again after getting the whole file.
Your situation is strange, cause it means your data got corrupted in the mean time or the client is not working well falsely thinking the piece in question is ok; which in fact is not the case since a manual check caught it.
I would advise you to really watch for your data. I am not an expert but I am really sure that when a torrent client gets a piece it calculates and checks its hash. I am as close as possible to be sure data your data somehow gets corrupted and verifying everything a second time should be seen as a valid solution. You really need to remove the cause mate, as it sound pretty dangerous to your files.
Well there is another possibility. The torrent client really screws the data itself somehow but I think it is less likely and you yourself said that you had checked two clients. Either way second check is not a proper solution. For you it better if the torrent clients were bugged. It would mean rest of your files are safe from this. If not it is the hardware most probably (not necessarily HDD) or the operating system or whatever utility that can get to your files.
Re: Always verify local data after torrent finishes.
The corrupted torrents all seem to come from a particular private tracker, so it could be someone intentionally or accidentally seeding bad data. Once I verify the local data after getting a crc error, it never becomes corrupt again, which makes me think it isn't hardware.
Re: Always verify local data after torrent finishes.
Still seem very very strange. At least to me. A piece is verified right after its downloaded. Could you please help me and present idea how the heck it can be reported corrupted afterwards ? This is what I don't get and can't imagine.
Well I can, but it involves such uncertain coincidences that I'd rule them out or a very malicious user who is bored ( or whatever he feels ) enough put quite effort in compromising the tracker and data sharing via torrent. That seems to me very awkward also.
For such situation to occur ( a piece is verified, then after some time reported corrupted ) must involve some data alteration. A hash function with the same argument ( a data chunk ) will always give the same result (would be useless otherwise, lol it would not be a function nvm ). So you have to get a corrupted piece in the first place, which is falsely reported as a good one ... or alter (i find 'damage' an unfortunate term) it later.
Now under assumption the Torrent client works like it should, there is only one possibility that you can get your piece falsely reported as a good. It has to 'look' as such. Means it would have to have the same hash value... and this by the definition of a 'good' hash function shall be extremely hard to produce and unlikely to occur, though not impossible. If you say ok might have happened, which if happened by accident, would make you like the most unfortunate person in he world (I think the odds are less than black hole in LHC and winning millions in a lottery is a common thing compared to that), then if you had verified it with out any alterations it would again be reported ok. But if somehow the unrar program did something to the portion of data it felt is corrupted, then it would get reported upon next verification a corrupted and redownloaded.
Either way, the data must be altered on your site. No other option, unless the client is screwed but I think more ppl would have notice, report and complain. Plus if you say it is not an error, then something modifies the file as something normal procedure (the only option I see slightest valid is this unrar, I don't see why would it but ... whatever something has to ) plus you would need someone really malicious that would send packets with bad data and the same hash. Sh*t that is what I call a long shot, it's really not that easy.
I understand your point, but I believe mine are also valid. I am quite curious what really is happening.
I also get why the requested option would somehow help you. But I hope you understand that this just a mediocre workaround without explaining the reason. It might help you but can't even be sure that it would always work. (Well still a weak temporary soulution might be better than none).
Cheers mate.
Well I can, but it involves such uncertain coincidences that I'd rule them out or a very malicious user who is bored ( or whatever he feels ) enough put quite effort in compromising the tracker and data sharing via torrent. That seems to me very awkward also.
For such situation to occur ( a piece is verified, then after some time reported corrupted ) must involve some data alteration. A hash function with the same argument ( a data chunk ) will always give the same result (would be useless otherwise, lol it would not be a function nvm ). So you have to get a corrupted piece in the first place, which is falsely reported as a good one ... or alter (i find 'damage' an unfortunate term) it later.
Now under assumption the Torrent client works like it should, there is only one possibility that you can get your piece falsely reported as a good. It has to 'look' as such. Means it would have to have the same hash value... and this by the definition of a 'good' hash function shall be extremely hard to produce and unlikely to occur, though not impossible. If you say ok might have happened, which if happened by accident, would make you like the most unfortunate person in he world (I think the odds are less than black hole in LHC and winning millions in a lottery is a common thing compared to that), then if you had verified it with out any alterations it would again be reported ok. But if somehow the unrar program did something to the portion of data it felt is corrupted, then it would get reported upon next verification a corrupted and redownloaded.
Either way, the data must be altered on your site. No other option, unless the client is screwed but I think more ppl would have notice, report and complain. Plus if you say it is not an error, then something modifies the file as something normal procedure (the only option I see slightest valid is this unrar, I don't see why would it but ... whatever something has to ) plus you would need someone really malicious that would send packets with bad data and the same hash. Sh*t that is what I call a long shot, it's really not that easy.
I understand your point, but I believe mine are also valid. I am quite curious what really is happening.
I also get why the requested option would somehow help you. But I hope you understand that this just a mediocre workaround without explaining the reason. It might help you but can't even be sure that it would always work. (Well still a weak temporary soulution might be better than none).
Cheers mate.