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):
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.
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 ?
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.
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
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:
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
See also original cdrtools patch:
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?
genisoimage is based on a very old and outdated mkisofs
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
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.