Re: [Nbd] [PATCH] Add "temporary" option, and ability to create files.

[Wouter Verhelst <wouter@...3...>]

On Thu, Jun 09, 2011 at 04:19:02PM +0100, Alex Bligh wrote:
> Wouter,
> 
> --On 9 June 2011 16:39:10 +0200 Wouter Verhelst <w@...112...> wrote:
> 
> > On Tue, May 31, 2011 at 10:54:09AM +0100, Alex Bligh wrote:
> >> This commit:
> >> * Adds a "temporary" option, which causes a unique file to be
> >>   created, which is unliked as soon as it is created (and thus
> >>   will not be present on exit). This is used for creation of
> >>   temporary disks.
> >> * Will create a file, if "filesize" is specified and the file
> >>   is not present or is zero length (useful in conjunction with the
> >>   above).
> >
> > I'd created the 'prerun' and 'postrun' stuff so that this kind of
> > behaviour could be implemented without having to special-case it. While
> > I have nothing against this particular patch per se, I'd be interested
> > in learning why you feel they're not sufficient before I'll accept it.
> 
> I think the answer here is because there is no way from prerun
> or postrun to feed back the name of the temporary file created. Just
> to be clear, what it's doing is creating a temporary file based on
> the pathname specified in the export session, and using that. So multiple
> clients can say "I want a 50Gig disk that will go away after I use
> it". Pre-run could create one, with a fixed filename, but I see
> no way to avoid overwriting the files of existing clients.

Search for 'virtstyle' in the manpage (though I have received vague bug
reports that it would be broken; I have not been able to confirm that
yet)

Granted, that's limited to one file per client. I suppose it could make
sense to have a 'virtstyle = script' wich would let a script define a
name, which it would have to report through stdout; that would also be
useful with other things.

> >> Available from git.alex.org.uk as usual.
> >>
> >> Wouter: please note my repo contains a revert of your recent patch
> >> to allow specification of the port in the config file, because it
> >> causes nbd-server to SEGV on "make check". You may or may not
> >> want to pull that.
> >
> > In the future, it's preferable if you do not merge a broken commit,
> > rather than adding another commit that reverts it. Because now I have to
> > either cherry-pick your commits, or revert your revert commit, both of
> > which are rather confusing :-)
> >
> > ("git checkout 53122e4d232; git branch -D master; git branch master"
> > would've done that, if you'd already merged before)
> >
> > I'll just do the cherry-pick thing this time, four commits isn't a huge
> > issue, but please remember that for the future.
> 
> This is my git-newbiness.

I guessed as much :-)

> The problem I had was that I did a
> git pull, assumed it would all work (fatal mistake!),

Yes, yes, sorry about that. I'll be more careful in the future, promise!

> did some
> patches of my own, committed them to my tree, then noticed the
> patch in master broke it. I couldn't see an obvious way to
> revert a patch in such a way that it didn't appear in the
> history, but still keep my own git history

You want 'git rebase'. See 'git help rebase'; there's an example in
there for how to deliberately lose some commits, too.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22