[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some intermediate thanks to Joerg Schilling



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 cdwrite-REQUEST@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org


Reply to: