On Thu, 2004-03-04 at 22:03, Joerg Schilling wrote:
> >Old-Return-Path: <[EMAIL PROTECTED]>
>
> >fixed the places that you mentioned manually. Please
> >be patient if I didn't get all of them right and perhaps
> >consider making cstyle available on your web site if you
> >expect patches to be csty
On Thu, 2004-03-04 at 22:03, Joerg Schilling wrote:
> >Old-Return-Path: <[EMAIL PROTECTED]>
>
> >fixed the places that you mentioned manually. Please
> >be patient if I didn't get all of them right and perhaps
> >consider making cstyle available on your web site if you
> >expect patches to be csty
Joerg Schilling wrote:
From: Rob Bogus <[EMAIL PROTECTED]>
The alternative would be to group them by function, such as putting
things which affect the device (dev=, speed=, burnfree, etc) in one
group, things which affect format (-D -R -N, etc) in another, things
which affect how the con
Joerg Schilling wrote:
From: Rob Bogus <[EMAIL PROTECTED]>
The alternative would be to group them by function, such as putting
things which affect the device (dev=, speed=, burnfree, etc) in one
group, things which affect format (-D -R -N, etc) in another, things
which affect how the co
>To: [EMAIL PROTECTED], cdwrite@other.debian.org
>But it seems that you have a strange editor:
>if (merge_image != NULL) {
>if (merge_previouS_session(ROOT, MROOTP,
>
> reloc_root, r
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>But it seems that you have a strange editor:
>if (merge_image != NULL) {
>if (merge_previouS_session(ROOT, MROOTP,
>
> reloc_root, reloc_ol
>Old-Return-Path: <[EMAIL PROTECTED]>
>> This is a program written by Bill Shannon (the inventor
>> of the vnode interface that also was the base for the NFS
>> rpc interface.
>I have been unable to find a homepage of Bill Shannon
>or cstyle, although he turns up in some Google hits,
>mostly rel
>Old-Return-Path: <[EMAIL PROTECTED]>
>> This is a program written by Bill Shannon (the inventor
>> of the vnode interface that also was the base for the NFS
>> rpc interface.
>I have been unable to find a homepage of Bill Shannon
>or cstyle, although he turns up in some Google hits,
>mostly rel
On Sun, 2004-02-29 at 22:04, Joerg Schilling wrote:
> >From: Patrick Ohly <[EMAIL PROTECTED]>
>
> >> The patch to the man page indserts things disordered
>
> >Where would you like me to insert the description of
> >the new options?
>
> A while ago, I did try to have the options in alphabetical o
On Sun, 2004-02-29 at 22:04, Joerg Schilling wrote:
> >From: Patrick Ohly <[EMAIL PROTECTED]>
>
> >> The patch to the man page indserts things disordered
>
> >Where would you like me to insert the description of
> >the new options?
>
> A while ago, I did try to have the options in alphabetical o
>From [EMAIL PROTECTED] Mon Mar 1 17:52:48 2004
>> Functional grouping makes it harder for the people who need the
>> manual because the know little about the program.
>That's illogical. If you know little about the program, you are
>unlikely to know what a command line switch is called. Rath
>From [EMAIL PROTECTED] Mon Mar 1 17:52:48 2004
>> Functional grouping makes it harder for the people who need the
>> manual because the know little about the program.
>That's illogical. If you know little about the program, you are
>unlikely to know what a command line switch is called. Rath
On Mon 1 March 2004 16:23, Joerg Schilling wrote:
> From: Rob Bogus <[EMAIL PROTECTED]>
>
> >The alternative would be to group them by function, such as
> > putting things which affect the device (dev=, speed=, burnfree,
> > etc) in one group, things which affect format (-D -R -N, etc)
> > in anoth
>From: Rob Bogus <[EMAIL PROTECTED]>
>The alternative would be to group them by function, such as putting
>things which affect the device (dev=, speed=, burnfree, etc) in one
>group, things which affect format (-D -R -N, etc) in another, things
>which affect how the content is scanned (-f, etc
On Mon 1 March 2004 16:23, Joerg Schilling wrote:
> From: Rob Bogus <[EMAIL PROTECTED]>
>
> >The alternative would be to group them by function, such as
> > putting things which affect the device (dev=, speed=, burnfree,
> > etc) in one group, things which affect format (-D -R -N, etc)
> > in anoth
>From: Rob Bogus <[EMAIL PROTECTED]>
>The alternative would be to group them by function, such as putting
>things which affect the device (dev=, speed=, burnfree, etc) in one
>group, things which affect format (-D -R -N, etc) in another, things
>which affect how the content is scanned (-f, etc
Joerg Schilling wrote:
From: Patrick Ohly <[EMAIL PROTECTED]>
The patch to the man page indserts things disordered
Where would you like me to insert the description of
the new options?
A while ago, I did try to have the options in alphabetical order.
This seems to be the best
Joerg Schilling wrote:
From: Patrick Ohly <[EMAIL PROTECTED]>
The patch to the man page indserts things disordered
Where would you like me to insert the description of
the new options?
A while ago, I did try to have the options in alphabetical order.
This seems to be the bes
>From: Patrick Ohly <[EMAIL PROTECTED]>
>> The patch to the man page indserts things disordered
>Where would you like me to insert the description of
>the new options?
A while ago, I did try to have the options in alphabetical order.
This seems to be the best when a command as s many options
>From: Patrick Ohly <[EMAIL PROTECTED]>
>> The patch to the man page indserts things disordered
>Where would you like me to insert the description of
>the new options?
A while ago, I did try to have the options in alphabetical order.
This seems to be the best when a command as s many options
On Sun, 2004-02-29 at 19:11, Joerg Schilling wrote:
> >From: Patrick Ohly <[EMAIL PROTECTED]>
>
> >I have updated the patch again to apply cleanly against
> >2.01a26pre. Patching the man page and a function prototype
> >caused conflicts while the rest applied still fine.
>
> Please try to create
>From: Patrick Ohly <[EMAIL PROTECTED]>
>I have updated the patch again to apply cleanly against
>2.01a26pre. Patching the man page and a function prototype
>caused conflicts while the rest applied still fine.
Please try to create less work for me..
The patch to the man page indserts things
On Sun, 2004-02-29 at 19:11, Joerg Schilling wrote:
> >From: Patrick Ohly <[EMAIL PROTECTED]>
>
> >I have updated the patch again to apply cleanly against
> >2.01a26pre. Patching the man page and a function prototype
> >caused conflicts while the rest applied still fine.
>
> Please try to create
>From: Patrick Ohly <[EMAIL PROTECTED]>
>I have updated the patch again to apply cleanly against
>2.01a26pre. Patching the man page and a function prototype
>caused conflicts while the rest applied still fine.
Please try to create less work for me..
The patch to the man page indserts things
On Mon, 2003-07-21 at 19:07, Patrick Ohly wrote:
> Hello everyone,
>
> I have updated the patch that adds -root and -old-root
> to mkisofs. It is now based on cdrtools 2.01a16,
I have updated the patch again to apply cleanly against
2.01a26pre. Patching the man page and a function prototype
cause
On Mon, 2003-07-21 at 19:07, Patrick Ohly wrote:
> Hello everyone,
>
> I have updated the patch that adds -root and -old-root
> to mkisofs. It is now based on cdrtools 2.01a16,
I have updated the patch again to apply cleanly against
2.01a26pre. Patching the man page and a function prototype
cause
Hello everyone,
I have updated the patch that adds -root and -old-root
to mkisofs. It is now based on cdrtools 2.01a16, but this
is not the major reason for the update, as the patch applied
to that version fine before. Instead it fixes a problem with
files in subdirectories from previous backups b
On Sat, 2003-04-12 at 13:22, Joerg Schilling wrote:
> >> This is why I don't trust mkisofs as backup tool - just because I never
> >> do complete checks with the created images.
>
> >Well, with my patch you can do such a check, even after an
> >incremental backup.
>
> >From reading you other stuf
> > > Proposed solution:
> > >
> > > The second new option
> > > -old-root
> >
> > Why not -old-root alone?
>
> When doing several incremental backups one would end up
> with a directory structure like this:
>
>
> backup_
>
>
> as Andy and Matthias have pointed out, Linux can mount different
> sessions, even at the same time. However, this does not address
> my following concerns:
> - no sessions with growisofs + DVD+RW (right? at least it only worked
> for me with CD-R)
That is correct! 'mount -o session=N ...' is n
Hi all,
as Andy and Matthias have pointed out, Linux can mount different
sessions, even at the same time. However, this does not address
my following concerns:
- no sessions with growisofs + DVD+RW (right? at least it only worked
for me with CD-R)
- no platform independent accesss to the backup
On Tue, Mar 25, 2003 at 08:38:05AM +0100, Patrick Ohly wrote:
> > > However, accessing older versions of a file is
> > > difficult: the CD filesystems must be able to select
> > > arbitrary session and thus the old file. At least on
> > > the Amiga this works, but I have doubts about Linux
> >
> >
> > However, accessing older versions of a file is
> > difficult: the CD filesystems must be able to select
> > arbitrary session and thus the old file. At least on
> > the Amiga this works, but I have doubts about Linux
>
> It's possible with 'mount -o session=N ...' under Linux.
Ah, good to kno
> However, accessing older versions of a file is
> difficult: the CD filesystems must be able to select
> arbitrary session and thus the old file. At least on
> the Amiga this works, but I have doubts about Linux
It's possible with 'mount -o session=N ...' under Linux. It should be
noted that ther
To all it may concern,
I have modified mkisofs 2.0 to make it more useful
for incremental backups. The patch is attached,
but it is not the final version - if people
are interested in using it, I'd also update the
man page and fix the remaining problems (see below).
I CC: James Pearson as he is l
35 matches
Mail list logo