When checking in files, Check for a crc32 hash in the filename

[GoogleCodeExporter]

This is essentially just looking in the filename for the hash and seeing if the 
hash and the computed hash match. Attached is a link to a python script that 
checks crc32s after finding them in the filename. 
http://agafix.org/anime-crc32-checksum-in-linux-v20/

Original issue reported on code.google.com by Dizzy...@gmail.com on 4 Mar 2011 at 9:08

[GoogleCodeExporter]

Sorry meant to make as enhancement. 

Original comment by Dizzy...@gmail.com on 4 Mar 2011 at 9:09

[GoogleCodeExporter]

Interesting idea. Can you provide an example of when this feature would be 
useful?

Original comment by ekb...@gmail.com on 4 Mar 2011 at 11:22

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I have a lot of videos files that are named like 
[group]Series_Name[Source]_[CRC32Hash]. And am currently using a large pooled 
nas to manage them. This would be useful to check that the file is still 
correct before importing it.

Original comment by Dizzy...@gmail.com on 5 Mar 2011 at 12:49

[GoogleCodeExporter]

Good ideas, but it seems that you can run the check before importing anyway :D

Original comment by uts...@gmail.com on 9 Mar 2011 at 4:19

[GoogleCodeExporter]

I have sometimes felt the need for a similar feature. I used to have md5sum 
lists for my files (before boar), and it'd be nice to use those lists when 
importing large amounts of data, to get an extra check that the data is 
imported correctly. However, there are many different kinds of commonly used 
checksums, and many different file formats for checksums (or even in the 
filename, as described in this issue). Trying to support some of these 
combinations is too much of a niche feature at this stage. It may be easily 
implemented as a separate plugin though. I'll look closer at that possibility. 
But as it is stated here, this feature will not be implemented in the 
forseeable future.

Original comment by ekb...@gmail.com on 15 Mar 2011 at 10:51

• Changed state: WontFix