Bug 77432

I'm assuming this means to produce an md5sums.txt file (as most linux distributions have at the toplevel) for all files being burned onto the CD/DVD.  I understand that the files from the hard drive may come from different places, so the md5sum routine would need to correct the path information, but this would be extremely helpful, even if it forced creation of an intermediate directory and/or ISO file.

After I made a single backup onto CD of a friend's home directory and not everything burned properly (discovered far after the fact), I *always* re-mount a burned cd and run (cd /media/cdrom; md5sum -c md5sums.txt) or the like, to verify that every byte on every file was burned correctly and is readable.  In fact, I just used that to verify that a knoppix DVD image I bittorrented was wrong (by mounting it via the loopback mechanism).

In particular, I'm burning a photo album and would like an automatically generated md5sums.txt file so I can verify the CD immediately after the burn, and perhaps a couple years afterwards to make sure all the bits are still good.

*** This bug has been confirmed by popular vote. ***

as for comment 1, why do you not use the verification option of k3b if you want to make sure that the cd burned correctly, or is the integrity of the individual files so important?

Case in point -- I once burned a CD (long ago, under IRIX) that appeared to burn correctly, but upon handing it to my friend and deleting the directory a month later, had him point out to me that not all of his precious data had made it onto the CD.  Since then, I've been paranoid about verifying data on burned media.

One case I've handled recently is a flaky drive.  I have a drive which as of a month ago will burn CDs properly, but won't read near che periphery.  In this instance, it's useful to know that a handful of files cannot be read, and then try the disc on another drive; in this case, a 'succeeded/failed' indication doesn't indicate whether the burning or reading functionality of the drive (or possibly something else altogether) is wrong.

Another possibility is weird bugs in the burner, defects in the media, or something in between.  An md5sum check performed immediately after burn, assures me that every single byte I burned made it onto the medium, accurately, and that anyone else who receives the medium should be able to run the same md5sum and get the same results -- if not, it's very clearly a problem with their equipment.

Finally, some time down the road, the medium could fail in spots (scratches, etc).  I could then pull most of the data off the medium, then use the md5sum file to find which files could not be transferred accurately, and hunt through older backups to replace those.

Having md5sums automatically generated and added would completely eliminate a certain kinds of uncertainty in troubleshooting various problems.  If I had my extremely paranoid way, I'd request that the md5sum be generated, then checked against the source files on the hard drive (to eliminate problems reading the files on the hard drive), then burned onto the medium along with the source files, then checked again against the files on the medium.  This would test the source files, the hard drive, the medium burning function, the burning process, the medium reading function, and the medium itself all in one user action.

Christoph:
1) k3b is not 100% reliable in doing verification because it is done on iso image level, not separate files
2) k3b verification verifies writing not reading, you take your disc to a friend and how can you be sure his drive read all data correctly?

All discs I burned so far has MD5SUMS file created manually. So my vote for this wish -- however I would opt for configurable MD5 filename.

Problem: the md5sum.txt-File modified the md5sum of the CD/DVD! The file is also calculating in the md5sum!

Kai, what do you mean? MD5 for whole disc is calculated when you are burning iso file, not the project with files. 

Btw. it would be nicely touch -- if the user creates (this way) MD5 file it could be used to verify burning instead of current implementation. So the problem with translating names and being unable to verify disc on file level would be solved too.