Hi, > > Well, compiling cdrecord on SuSE 9.0 is a bit cumbersome ... > > What kind of problems do you have?
I remember an undefined HZ caused by having a semi-100 and semi-1000 Hz kernel. I dimly remember that i had another issue (which will bite me again and remind me) when i compiled your first source release of DVD support a few months ago. (scdbackup's default for DVD is growisofs but cdrecord can be used too. I tested that - when i was not yet so completely overwhelmed by my newer roles.) > I would need to look for my Suse-9.x HDD again.... Oops. I did not want to instigate hardware efforts. I always was able to compile cdrecord, somehow. But my users are a bit less skilled with reading protest messages of gcc. For them cdrecord-ProDVD was a viable alternative to compiling. > > This i would use to chop oversized files (>650 MB, >=2 GB) > > without the need for buffering the parts on disk. > > (I will be able to tell exact sizes in advance.) > > I don't understand. Use case: With planning a backup on CD, my scdbackup encounters a file of 1 GB size. It won't fit. scdbackup needs a to do a workaround. So the user will get a chopped file. Better than nothing. Easy to restore. cat is my friend. Currently scdbackup copies the first 640 MB out of that file into a new file in a disk buffer directory. Then this disk file is given to mkisofs. -graft-points allows me to put it back into its appropriate directory in the ISO image. A name suffix tells the chunk number and the total number of chunks. The other 384 MB are later given to the next run of mkisofs | cdrecord for the next CD volume. Together with other files to fill up. The problem with this approach is: - the user needs buffer space on disk - i must protect those buffered files from spying and alteration (backup is a matter of privacy and security). With DVD, the problem is the same because i better do not expect a file of 2 GB or more to be readable on all systems. The buffer space needs are even larger. The user has to provide a full DVD size because mkisofs wants to see all the chunks of a volume simultaneously. My proposal would allow to generate them one by one and to pipe them into those new super-complicated pathspecs. (They are an imposition on you, i confess. Let them ripe a while on your todo list ... :) > > This feature would also allow very interesting stunts like > > file-by-file compression and/or encryption in a plain > > ISO tree. > > There is a non-standard (Linux only) RR extension in mkisofs for > compression and it my be that we will support this in future on Solaris. Interesting. What's the option name ? ... -z ? Ahum ... hey, that's something for my own todo ... ... mkzftree ... ahum ... again a reason to have disk buffer ? Will i never get rid of that ? :)) A usage example would help with the -z paragraph in man mkisofs (as of cdrtools-2.01.01a09). Like: " mkisofs /x/=/a/b /y=/c/d can be done with compression by mkzftree ... mkisofs ... " I will have to do some experiments. But my proposal is more general and it would isolate you from many particular enhancement wishes which could be fulfilled on user level then. Each of those pathspecs would be a stdin-inlet for arbitrary tricks and filterings. We all know the power of the pipe. I can imagine one mkisofs employing a dozen subsequential runs of star to create an ISO image with a dozen star-balls in it. On the fly. star can stand a few padding 0s. I know for sure. :)) Each of the pathspecs would result in one file in the ISO tree. The file's size would be predicted already at start of mkisofs. (Although mkisofs should expect the input having a deviating size and then correct that deviation brutally.) Whatever. You got your own priorities. For scdbackup it is most important that the old features are kept alive. For that i will test soon. > However, correct hard link handling and File size > 4 GB would be more > important. These are important features for scdbackup, too. The nearer the mkisofs result comes to a normal Linux filesystem, the better it is for backup purposes. (You did a lot for that in the last years. I noticed.) I would deem >4GB files in mkisofs very valuable. But i could hardly dare to use that feature as default for quite a while. There is lots of ISO reader software out there which does not even cope with >=2 GB. > > Copy the attributes of implicitely given directories into > Please check the recent mkisofs first.... I take this as a friendly RTFM. :) Give me a few days time to follow that advise. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
