[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] Add the ``--mount'' command line option
From: |
Sergiu Ivanov |
Subject: |
Re: [PATCH 1/3] Add the ``--mount'' command line option |
Date: |
Sun, 5 Jul 2009 19:17:33 +0300 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello,
On Fri, Jul 03, 2009 at 06:52:37AM +0200, olafBuddenhagen@gmx.net wrote:
> On Thu, Jun 18, 2009 at 11:14:41PM +0300, Sergiu Ivanov wrote:
> > @@ -124,6 +132,13 @@ argp_parse_common_options (int key, char *arg, struct
> > argp_state *state)
> > ulfs_match = 0;
> > break;
> >
> > + case OPT_MOUNT:
> > + /* TODO: Improve the mountee command line parsing mechanism. */
> > + err = argz_create_sep (arg, ' ', &mountee_argz, &mountee_argz_len);
> > + if (err)
> > + error (EXIT_FAILURE, err, "argz_create_sep");
> > + break;
> > +
> > case OPT_UNDERLYING: /* --underlying */
> > case ARGP_KEY_ARG:
> >
>
> 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.
> 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.
Should I just add this check or should error out some message, what do
you think?
> 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.
Have I answered your question or have I understood something wrong?
Regards,
scolobb