Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Ian Dowse

In message [EMAIL PROTECTED], Jos Backus writes:
 
 This was fixed some time ago, I thought.  Are you up to date?

There was a commit to mdmfs.c in August.
This is with yesterday's -current, sorry, should have mentioned that.

The mount -t mfs case doesn't work with mdmfs, because mount(8)
uses the filesystem name, not the mount_xxx program as argv[0]. I
had guessed this would be a problem when I read the commit message
for revision 1.7 of mdmfs.c, but then I forgot to mention it to
Dima.

Here is a patch that should help - it makes mdmfs accept mount_mfs
or mfs to trigger compatibility mode instead of mount_*.

Ian

Index: mdmfs.8
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mdmfs/mdmfs.8,v
retrieving revision 1.8
diff -u -r1.8 mdmfs.8
--- mdmfs.8 16 Aug 2001 07:43:16 -  1.8
+++ mdmfs.8 29 Sep 2001 23:50:29 -
@@ -304,9 +304,10 @@
 flag,
 or by starting
 .Nm
-with
-.Li mount_
-at the beginning of its name
+with the name
+.Li mount_mfs
+or
+.Li mfs
 (as returned by
 .Xr getprogname 3 ) .
 In this mode, only the options which would be accepted by
Index: mdmfs.c
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mdmfs/mdmfs.c,v
retrieving revision 1.7
diff -u -r1.7 mdmfs.c
--- mdmfs.c 16 Aug 2001 02:40:29 -  1.7
+++ mdmfs.c 29 Sep 2001 22:58:05 -
@@ -116,8 +116,9 @@
newfs_arg = strdup();
mount_arg = strdup();
 
-   /* If we were started as mount_*, imply -C. */
-   if (strncmp(getprogname(), mount_, 6) == 0)
+   /* If we were started as mount_mfs or mfs, imply -C. */
+   if (strcmp(getprogname(), mount_mfs) == 0 ||
+   strcmp(getprogname(), mfs) == 0)
compat = true;
 
while ((ch = getopt(argc, argv,




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Dima Dorfman

Ian Dowse [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], Jos Backus writes:
  
  This was fixed some time ago, I thought.  Are you up to date?
 
 There was a commit to mdmfs.c in August.
 This is with yesterday's -current, sorry, should have mentioned that.
 
 The mount -t mfs case doesn't work with mdmfs, because mount(8)
 uses the filesystem name, not the mount_xxx program as argv[0].

This seems to violate POLA.  Would something break if it was changed
to use mount_xxx (unforunately, I'm ~ 200 km away from my -current box
at the moment, so I can't try it myself)?

 I
 had guessed this would be a problem when I read the commit message
 for revision 1.7 of mdmfs.c, but then I forgot to mention it to
 Dima.
 
 Here is a patch that should help - it makes mdmfs accept mount_mfs
 or mfs to trigger compatibility mode instead of mount_*.

The problem with this is that in a bikeshed far, far in the past, some
people wanted to me able to call it mount_md instead of mount_mfs.
Of course, we could allow mfs and md, but that seems rather ugly
(what if someone wants fish?).  I'd rather see mount(8) use
mount_xxx, although if we think that would break something, your patch
is probably the best solution.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Jos Backus

On Sat, Sep 29, 2001 at 05:25:20PM -0700, Dima Dorfman wrote:
 The problem with this is that in a bikeshed far, far in the past, some
 people wanted to me able to call it mount_md instead of mount_mfs.

Hardcoding the fsname may not be terribly elegant but does work.

 Of course, we could allow mfs and md, but that seems rather ugly
 (what if someone wants fish?).  I'd rather see mount(8) use
 mount_xxx, although if we think that would break something, your patch
 is probably the best solution.
 
Fwiw, agreed on both counts.

Thanks Ian, for providing the (temporary?) fix.

-- 
Jos Backus _/  _/_/_/Santa Clara, CA
  _/  _/   _/
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Ian Dowse

In message [EMAIL PROTECTED], Dima Dorfman writes:

The problem with this is that in a bikeshed far, far in the past, some
people wanted to me able to call it mount_md instead of mount_mfs.
Of course, we could allow mfs and md, but that seems rather ugly
(what if someone wants fish?).  I'd rather see mount(8) use
mount_xxx, although if we think that would break something, your patch
is probably the best solution.

I can't think of any good reason not to change mount(8), but I also
think that mdmfs only needs to support the weird mount_mfs defaults
when invoked with a name of mount_mfs or mfs. People can call
it mount_fish if they like and it will work fine, just with the
mdmfs rather than mount_mfs defaults. The non-compatibility defaults
are better defaults anyway, so they should probably be used in all
cases except those that are necessary for compatibility with
mount_mfs.

Ian

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Kris Kennaway

On Sat, Sep 29, 2001 at 02:32:31PM -0700, Jos Backus wrote:
 It looks like /tmp is not getting the right permissions set (1777).

This was fixed some time ago, I thought.  Are you up to date?

Kris



msg31966/pgp0.pgp
Description: PGP signature


Re: mdmfs mount_mfs compatibility bug?

2001-09-29 Thread Jos Backus

On Sat, Sep 29, 2001 at 04:26:03PM -0700, Kris Kennaway wrote:
 On Sat, Sep 29, 2001 at 02:32:31PM -0700, Jos Backus wrote:
  It looks like /tmp is not getting the right permissions set (1777).
 
 This was fixed some time ago, I thought.  Are you up to date?

There was a commit to mdmfs.c in August.
This is with yesterday's -current, sorry, should have mentioned that.

 Kris

-- 
Jos Backus _/  _/_/_/Santa Clara, CA
  _/  _/   _/
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message