You are not logged in.
Hi,
I encountered a strange problem with k3b's "sort weight" option (under Advanced in the properties dialogue when you right-click on files in a data project). Unfortunately it was a couple of weeks ago and I don't really have the free time to investigate it properly, but here's what happened:
- I set some unimportant files to have a sort weight that would put them at the outer rim of the disc (I've found that this is where the vast majority of read errors start, so I want the less important files to be out there so that if the disc's gonna rot, they rot first).
- I burned the disc (a single-layer DVD-R), with 'verify written data' on.
- The burn and verify completed successfully.
- The file I set the 'sort weight' on was corrupted on the disc (apparently filled with random binary garbage).
This was quite disturbing, as, like I said, the verify completed successfully.
Here's what I think happened:
k3b's "sort weight" option (or the "sort weight" option in the underlying mkisofs) is somehow broken, causing the file's entry in the disc's table of contents to point to where it ought to be, if "sort weight" were working. In reality, however, the ISO image that k3b writes to disc is compiled as if "sort weight" was not used at all. This results in the file looking corrupted, because the TOC doesn't line up with the data.
To illustrate, suppose "xxx" represents data for file 'file1' and "yyy" is data for 'file2'. You burn a disc with file1 and file2 on it and don't use sort weight, and you get this:
data on disc: xxxxxxxyyyyyyyyyyyyyy
TOC on disc : [file1]
[file2.......]Now, you burn the same disc, but with file1 given a sort weight that puts it at the end of the disc (I can never remember if this is achieved with a positive or a negative sort weight and I wish k3b would include a pictogram, but that's a whole other rant...). The disc you get looks like this:
data on disc: xxxxxxxyyyyyyyyyyyyyy
TOC on disc : [file1]
[file2.......]Or, I suppose, possibly this (if I've got it backwards and data layout obeys "sort weight" but the TOC is wrong):
data on disc: yyyyyyyyyyyyyyxxxxxxx
TOC on disc : [file1]
[file2.......]In either case, you get a piece of file2 when you try to access file1, which is what I had happening. I was able to confirm this -- with much swearing and a hex editor I was able to locate the data that belonged to the file that I had assigned a "sort weight". Unfortunately, I don't remember which of the above two cases is true (I don't remember whether I found the data at the beginning or the end of the disc).
So, I think this issue needs some investigation and a proper bug report, and I would be grateful if someone here could do it. Unfortunately I don't have the time, but I thought I'd post this anyway, as a caution to you all -- sort weight is quite probably broken in k3b, and be very careful if you use it!
Also, k3b's data verification method is badly flawed. It confirms that what went on the disc is what k3b meant to write to it, but if k3b made a mistake in the iso layout, it'll just verify that it successfully wrote garbage. It does NOT go through and verify that the files on the freshly written disc match the files on your hard drive.
I can see why they did it this way: doing a file verify wouldn't work for things like audio CD's or video DVD's, and would also potentially miss bad sectors in metadata areas of the new disc that an ISO comparison *would* catch. Nonetheless, in this particular case, k3b's verify failed to catch a very important error, so I would advise everyone not to rely on k3b's verify option if the data on the disc is important.
~Felix.
Offline
Just found my notes from when this happened:
- I was using UDF large file support, which may be relevant (as it may be that only the UDF tables are wrong; maybe the normal ISO 9660 ones are OK after all).
~Felix.
Offline