[Top][All Lists]

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

Re: [PATCH 1/3] Add the ``--mount'' command line option

From: olafBuddenhagen
Subject: Re: [PATCH 1/3] Add the ``--mount'' command line option
Date: Fri, 10 Jul 2009 03:23:29 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


On Sun, Jul 05, 2009 at 07:17:33PM +0300, Sergiu Ivanov wrote:
> On Fri, Jul 03, 2009 at 06:52:37AM +0200, olafBuddenhagen@gmx.net
> wrote:

> > This surely needs some special handling in netfs_append_args() as
> > well?...
> Yes, it does, of course.  I didn't implement it right here because I
> misunderstood your suggestion to implement the union mount
> functionality *before* any command line handling.
> However, from my experience with using git, I'd say it shouldn't be
> very hard to insert a patch which adapts the behaviour of
> netfs_append_args.

Well, it should go into the same patch: without it, you get a translator
that doesn't properly handle fsysopts -- and as I said before, generally
we should try to have a fully working program at any point in a patch

> > BTW, what happens if the user specifies multiple --mount options?
> > From the looks of it, it won't blow up completely, but won't really
> > handle it in a useful way either?
> >
> > (A useful way would be either erroring out, or using only the latest
> > option and ignoring the others.)
> It won't blow up completely, right.  In the current implementation it
> *will* actually use the last option.  To make this behaviour
> completely safe, I should check whether the mountee_argz has already
> been allocated, because presently using multiple --mount options will
> result in memory leaks.

OK, that was my interpretation as well.

> Should I just add this check or should error out some message, what do
> you think?

I'm quite undecided myself :-(

Just pick what seems most useful to you I'd say -- we can still change
it later...

> > Another case I wonder about is mixing of --mount and "ordinary"
> > arguments -- is it actually possible to do that?
> I did nothing which could limit the functionality of unionfs.
> Therefore, I'd suppose that you can mix things however you want.  For
> instance, the following works for me:
>  $ settrans -a foo unionfs -a /boot/ -u -t /hurd/filterfs
> (filterfs is my old filtering translator which I use for testing
> purposes; it mirrors /var/tmp/)
> By ``works'' I mean that I can go under foo/ and do all normal
> operations on a filesystem.

OK, this is more or less what I expected.

It seems to me that mixing won't be possible in proxy mode though -- but
that's for later :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]