public inbox for linux-xfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox