GNOME Bugzilla – Bug 591959
Checksum computation broken on files >4GB
Last modified: 2018-09-21 16:44:02 UTC
Hi! I've just burned a DL DVD that contained a file that was bigger than 4GB. Brasero detected this case correctly and displayed a warning that the result wouldn't work on MacOS. The burning process finished without an error, but the data verification failed on the >4GB file (all others passed the test). However, I did my own test and computed the checksum of both files using "md5sum" (on Ubuntu 9.04) and they are equal! Unfortunately, I did not save the logfile. But I examined it, and everything seemed OK, except for the checksum of that particular file. Steps to reproduce: Enable the image checksum plugin and burn a DVD with a file bigger than 4GB (please don't ask me to attach one ;) Regards JK
Thanks for that report. (In reply to comment #0) > Enable the image checksum plugin and burn a DVD with a file bigger than 4GB > (please don't ask me to attach one ;) > I won't ;). I recently fixed a problem that happened with DVDs -R(W) and +R only. The problem was that a session for these media is always aligned on a 16 sector boundary padding the session if the image is not big enough. Therefore the size reported through MMC commands for a written track was not the same as the one of the image written which explained differing checksums. Please could you test if the fix helped fixing this bug?
I'll test this but it may take a while. Since I don't want to "waste" DL DVDs (they're still pretty expensive) I'll probably need a DVD-RW... But honestly, it doesn't sound like your fix has something to do with the bug. If I understood it correctly, the whole session is aligned, not any particular files. If the file-checksums would be influenced by the padding, then all checksums would be incorrect, isn't it? And the checksum computed by 'md5sum' would then be incorrect too, imho. I've burned a couple of DVDs in the past weeks (only "data projects", no images) and never had problems with checksums. Even on that particular DVD, it was only the >4GB file... If you don't want to wait, you can create a test-file by doing sth. like: dd if=/dev/urandom of=/tmp/fat_one bs=1024 count=4200000 and try to burn it. But you probably already knew this ;) Regards JK
I seems to me brasero calculate session checksum (or whatelse) and compare it to file checksums. It was data project, each file was ~1.5Gb in size. As you can see, file checksums are good but compared to "d41d8cd98f00b204e9800998ecf8427e (current)" all three times. This is wrong. $ cat /tmp/brasero_tmp*.md5 8b4328665b8d3c02fe3a34f4c23f7e5c arch3.tar.bz2 31d77ce56834c222d4ed6a5317dc042e arch.tar.bz2 262bd80d7f835f32aa36ee29ef9191b7 arch2.tar.bz2 $ tail brasero-session.log Preparing to checksum (type 4 .checksum.md5) (brasero_burn_record_session brasero-burn.c:2364) BraseroChecksumFiles called brasero_job_get_output_type BraseroChecksumFiles called brasero_job_get_action BraseroChecksumFiles called brasero_job_get_action BraseroChecksumFiles called brasero_job_get_action BraseroChecksumFiles called brasero_job_get_current_track BraseroChecksumFiles called brasero_job_get_current_track BraseroChecksumFiles Found file 0x9efb868 BraseroChecksumFiles called brasero_job_set_current_action BraseroChecksumFiles Getting file /arch3.tar.bz2 BraseroChecksumFiles comparing checksums for file /file3.tar.bz2 : 8b4328665b8d3c02fe3a34f4c23f7e5c (from md5 file) / d41d8cd98f00b204e9800998ecf8427e (current) BraseroChecksumFiles Wrong checksum BraseroChecksumFiles Getting file /arch.tar.bz2 BraseroChecksumFiles comparing checksums for file /file.tar.bz2 : 31d77ce56834c222d4ed6a5317dc042e (from md5 file) / d41d8cd98f00b204e9800998ecf8427e (current) BraseroChecksumFiles Wrong checksum BraseroChecksumFiles Getting file /arch2.tar.bz2 BraseroChecksumFiles Tried to set an insane progress value (1,500000) BraseroChecksumFiles comparing checksums for file /arch2.tar.bz2 : 262bd80d7f835f32aa36ee29ef9191b7 (from md5 file) / d41d8cd98f00b204e9800998ecf8427e (current) BraseroChecksumFiles Wrong checksum BraseroChecksumFiles called brasero_job_error BraseroChecksumFiles finished with an error BraseroChecksumFiles asked to stop because of an error
It was Brasero 2.28.2 on Ubuntu 9.10.
Note: file*.tar.bz2 instead of arch*.tr.bz2 is a my typo in log. Original file name does not matter.
Reopening as the requested information has apparently been provided.
Any news about this bug? Does anyone experience it with more recent versions?
It happens to me with Brasero 3.6.1 running on ubuntu 13.04 amd64.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/brasero/issues/68.