From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050810 Red Hat/1.7.10-0.90.1.legacy Description of problem: When I make a backup data CD-R using k3b, I set the Preserve file permissions (backup) checkbox, under the Filesystem tab of the Data Project window, as well as Generate Rock Ridge extensions (which was checked by default). The resulting CD-R does indeed preserve all file permissions, but not the permissions of directories. The directories all have the mode set to 555 (dr-xr-xr-x), which is a pain because when I copy these backup discs to a hard drive, the directories are no longer writeable by their respective owners. This bug is fixed in the upsteam k3b-0.12.5 release. It would be wonderful if you'd build an update RPM for FC4 from this! I've tried but can't figure out which parts of which patches from 0.11.23-3 need to be applied to the new source. What's more, I can't even rebuild the k3b-0.11.23-3 from the src.rpm, so something is different on my FC4 system than on your build system. I've installed all the RPMs that the build depends on, as listed in the k3b.spec file. Can I leave this all in your hands? I need this fix soon, but I don't know how much more time I can afford to spend trying to build it from source. Version-Release number of selected component (if applicable): k3b-0.11.23-3 How reproducible: Always Steps to Reproduce: 1. Launch k3b. 2. Start a data CD or DVD project, select the files you want. 3. Set the "Preserve file permissions (backup)" checkbox and burn the CD. Actual Results: All directories on the CD are mode 555. Expected Results: Directory modes should reflect those of original data. Additional info:
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Sorry for the delay. I just confirmed that the bug still exists in FC6 with k3b-0.12.17-1 installed. However, the upstream source for k3b should now have a partial fix, as indicated in http://bugs.kde.org/show_bug.cgi?id=83617 (comments 3-6) back in October 2005. In comment 9 of that same report, Chris Burghart offered a patch for an alpha release of cdrtools to make the corresponding fix to mkisofs. I don't know if that patch made it into the upstream source for cdrtools, but cdrtools is now in a much later alpha release. FC6 includes a standalone mkisofs package which I'm assuming is based on the older stable release of cdrtools. I'm still using the workaround I reported in comment 6 of the kde.org bug report above, to get around this problem, which works for me but is not ideal. I didn't try the mkisofs patch because I didn't want to have to mess with patching an alpha release of cdrtools on our production system when my workaround did the trick for us. If you can try it with a fixed mkisofs, and that solves the problem, then maybe an updated rpm for mkisofs is all you need to close this bug. I'll leave it to the Fedora folks to decide if the alpha mkisofs is stable enough to release as an update, or if Chris's "graft point" patch can be adapted to work with the stable version of mkisofs you're currently distributing. The steps to reproduce the problem are still the same as I reported above. I should add that in step 3, that checkbox is under the Filesystem tab of the dialog box that you get when you press the Burn button in the main K3b window. All you need to do is add a directory or two to your Data CD project, making sure the directories have write permissions on to begin with, and burn an ISO image file. You can then mount the image file using "mount -o loop ..." to see if the resulting directories in the image have the correct permissions.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
I have confirmed the problem still exists in Fedora rawhide's k3b-1.0.4-6.fc9, as well as in RHEL 5's k3b-0.12.17-1.el5. This can be confirmed either by burning a Data CD or Data DVD project, or by simply creating an ISO image from K3b. In the latest version of k3b, you can get to the "Preserve file permissions (backup)" option by clicking the "Custom..." button under the Filesystem tab of the Data Project dialog box. Rawhide's mkisofs is implemented by genisoimage (version 1.1.6-11.fc9), which has the same limitation in its implementation of the -graft-point option as earlier versions of mkisofs (such as mkisofs-2.01-10 in RHEL 5). The man page for mkisofs on either rawhide or RHEL 5 also confirms this limitation -- it creates the graft point directories with mode 0555 by default, rather than preserving the mode of the original directories. As a workaround, I set -new-dir-mode 0775 in the mkisofs user parameters in K3b's configuration, which works for our purposes, but isn't as ideal as K3b/mkisofs preserving the original directory modes. The original discussion of this bug in K3b on the KDE bugs site, at http://bugs.kde.org/show_bug.cgi?id=83617 included a patch for mkisofs, from Chris Burghart, which solved the last part of this problem (the first part having been fixed by Sebastian Trueg in the K3b source). But this patch has still not made its way into the upstream mkisofs source. Maybe the cdrkit.org maintainers of genisoimage will be more receptive to this fix than the maintainer of the cdrecord/cdrtools source was.
ccing you rdieter as harald appears to no longer maintain this package and bug still exists in F9 Rawhide
Afaict, from reading existing reports is that the problem is out of k3b's hands, and the remaining issues are with mkisofs (and friends). That is, unless I'm missing something?
Reassigning. See also original cdrtools patch: http://bugs.kde.org/attachment.cgi?id=13199&action=view
Fixed in rawhide cdrkit-1.1.8-1.fc10
That fix in cdrkit seems to have done the trick. Thanks! I hope it'll make it upstream to the source too. By the way, you may want to update the man page for genisoimage as it still says it uses mode 0555 for graft points by default. Any chance of this fix also making it into mkisofs-2.01-10.i386.rpm (cdrtools-2.01-10.src.rpm) on RHEL 5? Another point, though: Not to be nitpicky or anything, but this patch to mkisofs effectively disables the -new-dir-mode option, at least for graft points, presumably because the graft points are no longer treated as new directories. This may lead to some complaints if some users have come to rely on this option to override the default mode for graft points, as they'll no longer be able to do so (at least not with this option -- the more drastic -dir-mode still works). This may be a debatable point, but it might make more sense if -new-dir-mode overrode the default mode of the graft point even with this patch in place. (I'm not sure there are other contexts in which mkisofs would create new directories, and in which the -new-dir-mode option would still have an effect.) In any case, thanks, this is a big improvement.
It is upstream already. Man pages should be fixed, you're right. Can you please open bug against it? Now there isn't any open bug against cdrtools on RHEL5 with this issue. -new-dir-mode issue should be documented in man pages, I think. The same as above, can you please open ne bug? Thank you.
genisoimage is based on a very old and outdated mkisofs version. You most likely did not use the original software. As the original software is well maintained software, there have been many bug fixes for mkisofs during the past 3 years and the patch mentioned above is just one of many bugfixes needed in order to support correct file/directory permissions in the resulting filesystem tree. As the original mkisofs replaced ~30% of the source code for bug fixes and feature enhencements, it does not make sense to use the outdated close shipped by RedHat. I recommend you to upgrade to recent original software from ftp://ftp.berlios.de/pub/cdrecprd/alpha/
Since this is fixed in current releases closing this issue. Feel free to reopen if the problem still exists after upgrading to the current version.