GNOME Bugzilla – Bug 614522
Brasero silently loses directories (and associated data)
Last modified: 2018-09-21 17:01:30 UTC
I can reproduce this with brasero on both Ubuntu Lucid and Karmic. I add a directory tree to brasero, and when it finishes adding, there are files silently discarded. The lost directory is: converted-to-tar/DRIVE-I\ \(WORK\)/NJB/DEVTECH/2BPORTED/YACL/ which contains files and a subdirectory. A weird thing is that I have a second, parallel, directory tree: recovered-drives/DRIVE-I\ \(WORK\)/NJB/DEVTECH/2BPORTED/YACL/ which appears completely when I drag both to brasero. The primary difference is that the latter directory contains everything, and the former (failing) tree contains the same tree structure, but only tar files converted from older archive formats found in the source tree. The same burn works perfectly with Fedora 11 (brasero 2.26.3). And look at the difference in the .ISO file sizes: -rw-r--r--. 1 noel noel 5074489344 2010-03-18 11:36 piccolo-bad.iso -rw-rw-r--. 1 noel noel 5090373632 2010-03-18 12:17 piccolo.iso brasero on Karmic works a bit differently than on Lucid. On Karmic, I'll be asked if I want to add the directory, because it is so far down in the tree, and that question will be repeated. On Lucid, I am asked just one. On Karmic, if I had *just* that one tree, it actually works, but if I add that tree along with its peers, it silently fails. On Lucid, it fails in all cases. FWIW, I prefer Karmic's handling, where it offered NEVER, NOT THIS ONE, JUST THIS ONE, and ALWAYS, rather than NO and ALWAYS. I agree that if I want the option at all, I'm inclined to chose ALWAYS, but at least having the options was better than now. Even if I manually repair the project by dragging the missing directory into its place in brasero, brasero will silently drop the contents when burning! ALL FAILURES ARE SILENT. The image contains over 33,000 files and over 1200 directories. Were it not for the fact that I always store an md5sum.txt file in the root of the image, and always verify the burn with it, I would likely not have noticed the missing files until after the data might have been permanently lost. I CONSIDER THIS CRUCIAL TO RESOLVE ASAP! Silent data loss is unacceptable. Am marking it as CRITICAL because of the criteria: "causes loss of data," See also https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/541019
See https://bugzilla.gnome.org/show_bug.cgi?id=630651#c2 for a log of this problem being manifest.
FWIW, libburn, exercised on the same directory tree by: $ xorriso -outdev /home/noel/Desktop/xorriso.iso -add * works perfectly. genisoimage fails miserably, having major issues with deep paths, regardless of passing the necessary options.
This bug is still broken in 2.32.0, even after applying the fix for bug 630651. The failure can be seen after adding the directory tree and then checking it in the GUI. As part of verifying the image, I always run an md5sum check based on my own md5sum file taken in the file system, and the result of the verification can be seen here: $ grep -v OK check ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/old/yacl-012.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/old/yacl0121.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/old/yaclos2.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/old/yaclwin.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/yacl0130.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/yaclcsmp.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/yaclos2.tar: FAILED open or read ./converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL/yaclwin.tar: FAILED open or read The entire YACL directory was skipped, as discussed in the original post.
-- 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/100.