Summary: | app-cdr/cdrtools-3.00 - a text file becoming garbage after burning (or making an image) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | PM <mitaspiotr> |
Component: | Current packages | Assignee: | Daniel Pielmeier <billie> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | media-optical, xmw |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.kde.org/show_bug.cgi?id=251464 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
PM
2010-11-02 15:47:36 UTC
I guess you will have more luck on this if you report this issue to the cdrtools mailing list [1]. The author of cdrtools is also active on the gentoo-user mailing list [2]. [1] https://lists.berlios.de/mailman/listinfo/cdrecord-support [2] http://www.gentoo.org/main/de/lists.xml From upstream bug report: I also noticed, that this bug also manifests itself in an iso image created with k3b. So it's mkisofs issue. If this is a mkisofs bug you should try to reproduce this issue by using mkisofs only and report success or failure here. There is still a chance k3b is messing something up. Your report is not repeatable as you did not send any related information that would allow to understand your problem. I would thus give this report the unconfirmed status with respect to cdrtools. First a note: cdrtools-3.00 is a dead product. There will be no changes regardless of what is reported. If you detect something that does not look correct, you should first check the latest release. Also note: K3b calls mkisofs in really weird ways and it's debug output does not include all needed information to repeat a case..... so please use plain mkisofs command lines to create a test case. As structural problems are hard to repeat in general, you need to create a test case that is independent from e.g. file ordering in source directories (see readdir() and btree vs. create time ordering). Also try to make a test case as simple as possible. To repeat a case, I need all files including content in case that the content of a file controls mkisofs (or at least all file sizes and file names). Note that a year ago, someone reported a similar problem and even send all needed information. I could repeat the case and no problem was found - maybe because I fixed a bug with sorting and files > 4 GB in November 2010 already. Also note that it may be that some problems with files > 2 GB are really caused by bugs in the kernel file system implmentation. Linux e.g. is known to show strange timestamps if you use mkisofs -R -long-rr-time which is desired, as it permits to have a time stamp resolution finer than 1s. Maybe you now see why it is a bad idea to use older versions..... 3.00 is from June 2010 this is 19 months ago and 74 file changes (just for mkisofs) in 28 commits have been applied since 3.00. Hi Joerg, thanks for showing up! As you can see I reported this bug over a year ago and didn't notice this issue later, so it may be already fixed. On the other hand I don't remember burning any movies later either... I tried to reproduce this just now with 3.01_alpha06 and was unsuccessful. However I have another really weird problem with burning files over 4.4GiB in this release. Could you please take a look at https://bugs.gentoo.org/show_bug.cgi?id=343857 ? I am not sure whether this is your intention, but your link is a self reference to this report (In reply to comment #6) > I am not sure whether this is your intention, but your link is a self reference > to this report He most likely meant bug #394553. (In reply to comment #7) > (In reply to comment #6) > > I am not sure whether this is your intention, but your link is a self reference > > to this report > > He most likely meant bug #394553. Yes. Sorry. In comment 5 I also meant files over 4 GiB, not 4.4 GiB. It was late... How do we proceed here? Is this the same issue as in bug #394553 and we can close it as duplicate? If it is a separate issue can you test if creating the iso and burning it without k3b works? (In reply to comment #10) > How do we proceed here? Is this the same issue as in bug #394553 and we can > close it as duplicate? If it is a separate issue can you test if creating > the iso and burning it without k3b works? As I said in comment 5 I was no longer successful in reproducing this, so I'll just set it as resolved fixed. |