Version: 0.11.9 (using KDE KDE 3.2.2) Installed from: RedHat RPMs OS: Linux I'm using k3b-0.11.9-3.i386.rpm on Fedora Core 2. When I make a backup data CD-R, 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. I'm using mkisofs-2.01-0.a27.4, which may or may not be significant. I don't know exactly how k3b calls mkisofs, and how it sets up the data for it, so I couldn't say whether the bug is right in k3b or in mkisofs. I do know that earlier versions of mkisofs, with the -R option instead of -r, did not exhibit this behaviour.
This bug is the only thing at this point that keeps me from using k3b for backups. I love the convenience of a backup that looks like the original: I can mount it as a normal filesystem, browse it, and copy directly from it. With bad directory permissions on the backup, however, it is impossible to easily recreate the original filesystem from the copy. Because of the k3b bug, I am still using mkisofs + cdrecord by hand to create CD/DVD-based backups.
It's been over a year since I reported this problem. I'm now using Fedora Core 4, and k3b-0.11.23-3 still has the same bug. Is there any chance of getting this problem looked at? My boss is suggesting we buy the Linux version of Nero rather than fighting with this, but I'd much rather have an open-source backup solution.
SVN commit 471873 by trueg: Hack to keep the directory permissions. BUG: 83617 M +3 -0 ChangeLog M +3 -1 libk3b/projects/datacd/k3bdatadoc.cpp M +7 -0 libk3b/projects/datacd/k3bdiritem.h M +40 -6 libk3b/projects/datacd/k3bisoimager.cpp M +3 -1 src/projects/k3bdataurladdingdialog.cpp --- branches/stable/extragear/multimedia/k3b/ChangeLog #471872:471873 @@ -6,6 +6,9 @@ * Properly set the permissions on cdrecord versions >= 2.01.01a02 * Fixed the "Disabled start button in Copy dialog" bug. * Little window layout fix in K3bSetup2. + * Always use sector size 2048 when only creating an image in CD Copy. This means extracted + iso images from CDs with non-Mode1 tracks are useable again. + * Preserve directory permissions and user/group id in data projects when using the "backup" option. 0.12.4 ====== --- branches/stable/extragear/multimedia/k3b/libk3b/projects/datacd/k3bdatadoc.cpp #471872:471873 @@ -166,8 +166,10 @@ // QFileInfo::exists and QFileInfo::isReadable return false for broken symlinks :( if( f.isDir() && !f.isSymLink() ) { - if( !newDirItem ) + if( !newDirItem ) { newDirItem = new K3bDirItem( k3bname, this, dir ); + newDirItem->setLocalPath( url.path() ); // HACK: see k3bdiritem.h + } // recursively add all the files in the directory QStringList dlist = QDir( f.absFilePath() ).entryList( QDir::All|QDir::System|QDir::Hidden ); --- branches/stable/extragear/multimedia/k3b/libk3b/projects/datacd/k3bdiritem.h #471872:471873 @@ -71,6 +71,9 @@ */ virtual bool isFromOldSession() const; + void setLocalPath( const QString& p ) { m_localPath = p; } + QString localPath() const { return m_localPath; } + private: /** * this recursivly updates the size of the directories. @@ -89,6 +92,10 @@ KIO::filesize_t m_size; long m_files; long m_dirs; + + // HACK: store the original path to be able to use it's permissions + //
Unfortunately, this fixes only part of the problem. There is currently a bug in mkisofs that causes all of the directories created via k3b to have the same owner and permissions. Basically, the problem is that mkisofs always creates "graft points" with default ownership and permissions, and k3b creates *all* directories in its images as mkisofs graft points. I have reported this bug to Joerg Schilling, the owner/maintainer of mkisofs, and given him code that fixes the bug. With luck, he will integrate the fixed code into the working version of mkisofs. In addition, this will still leave a (smaller) bug in k3b. The fix Sebastian gives above addresses getting the ownership and permissions right for directories, but it will not leave correct times (creation, modification, and access) for the directories. I suspect that fixing it would require abandoning the creation and use of proxy dummy directories in building an image. That would be a significant job... For me, the times on the directories aren't very important anyway, if the ownership and permissions are correct.
In my previous comment, I forgot to mention that with Sebastian's fix above, and with my tweaked version of mkisofs, my "backup" images generated from k3b have directories with correct ownership and permissions. Yeah! :-)
Thanks, Sebastian and Chris. After spending a lot of time building the new release of k3b as an RPM for FC4, and testing and looking at the code to figure out why it still didn't fix the problem, I came to the same conclusion as you did, Chris. That's very frustrating. I ended up adding -new-dir-mode 0775 to the mkisofs user parameters to override the troublesome 0555 mode, which will do for our purposes until mkisofs is fixed. How I wish I had studied the mkisofs man page in the first place. I could have saved myself a lot of time. Let me know how Joerg responds to your bug report. Could I also get a copy of your patch to mkisofs? Sometime when I have another day to kill, I may work it into a new mkisofs RPM if Joerg and/or Red Hat don't beat me to it.
I added the time part to the dummy dir. so k3b 0.12.6 will also store the correct access times.
Sebastian, have you considered removing the dummy directories when k3b is done? Otherwise, it will be possible to really fill up ~/.kde/share/apps/k3b/temp with useless directories after just a few runs of k3b.
Created attachment 13199 [details] patch for cdrtools-2.01.01a03 Gilles, I'm attaching my patch for mkisofs that can be applied to the cdrtools distribution here: ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a03.tar.bz2 After unpacking the above source and getting the patch: $ cd cdrtools-2.01.01 $ patch -p1 -b < mkisofs_graft_points.patch Then you can build cdrtools. For Fedora Core 4, plain old "make" (which is really gmake) works fine.
at this moment i am implementing the removing of the dummy dirs. > >