[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) |
Hi,
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
series.
> > 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 :-)
-antrik-