All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Kendall <wkendall@sgi.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: nscott@aconex.com, xfs@oss.sgi.com
Subject: Re: But wait, theres more... [Fwd: Bug#415123: -R option can't append to a plain file]
Date: Wed, 21 Mar 2007 21:37:15 -0600	[thread overview]
Message-ID: <4601F9EB.30201@sgi.com> (raw)
In-Reply-To: <17CB3A8C59A80064581C0A32@timothy-shimmins-power-mac-g5.local>

Tim summed it up pretty well. I'd agree it's more of
a feature request. In case it isn't clear, the way
to resume a dump to a regular file is to point xfsdump
at a new file, just like incremental dumps go in a
different file than the base dump.

Bill

Timothy Shimmin wrote:
> Hi,
> 
> I'll leave this to Bill. Just a couple of comments.
> 
> I don't know if you can call it a "bug", more of a restriction.
> There is a layer provided for the I/O using drive_*.c -
> i.e drive_scsitape.c, drive_minrmt.c, drive_simple.c (which show up
> as a "drive strategy" on output).
> As part of the ds_instantiate() interface one typically sets up the 
> d_capabilities
> that this drive strategy supports and for files (drive_simple), 
> DRIVE_CAP_APPEND is
> not given. What the ramifications for drive_simple (file strategy) are,
> I wouldn't know without looking at the code and playing with it.
> But I'd call it an RFE :)
> 
> --Tim
> 
> --On 19 March 2007 8:23:13 AM +1100 Nathan Scott <nscott@aconex.com> wrote:
> 
>> And a free set of steak knives if you fix this bug...  ;-)
>>
>> -------- Forwarded Message --------
>> From: Peter Chubb <peterc@gelato.unsw.edu.au>
>> Reply-To: Peter Chubb <peterc@gelato.unsw.edu.au>,
>> 415123@bugs.debian.org
>> To: submit@bugs.debian.org
>> Subject: Bug#415123: -R option can't append to a plain file
>> Date: Fri, 16 Mar 2007 19:54:37 +1100
>>
>> Package: xfsdump
>> Version: 2.2.38-1
>>
>> If I use xfsdump to dump to a plain file, interrupt it, then restart
>> with the -R option, xfsdump complains:
>>
>> xfsdump: ERROR: media contains valid xfsdump but does not support append
>>
>> which is misleading: of *course* you can append to a regular file if
>> there's space on the filesystem.
>>
>> -- 
>> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT 
>> gelato.unsw.edu.au
>> http://www.ertos.nicta.com.au           ERTOS within National ICT 
>> Australia
>>
>> -- 
>> Nathan
>>
> 
> 
> 

      reply	other threads:[~2007-03-22  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 21:23 But wait, theres more... [Fwd: Bug#415123: -R option can't append to a plain file] Nathan Scott
2007-03-20  3:26 ` Timothy Shimmin
2007-03-22  3:37   ` Bill Kendall [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4601F9EB.30201@sgi.com \
    --to=wkendall@sgi.com \
    --cc=nscott@aconex.com \
    --cc=tes@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.