Hi,
I gave them the same name on purpose.
They are basically the same thing,
however, according to my docs, the statuscodes only have a welldefined
meaning for v3.
v1 and v2 have no statuscodes defined in mount.x
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxxxxx>
To: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Wednesday, March 14, 2001 4:46 AM
Subject: Re: [Ethereal-dev] packet-mount.c
> On Tue, Mar 13, 2001 at 11:36:05PM +1100, Ronnie Sahlberg wrote:
> > I have updated packet-mount.c to be tvbuff-ified.
> >
> > I also changed the output of MOUNTPROC_EXPORT[ALL] slightly.
>
> Checked in.
>
> You might want to give hf_mount1_status and hf_mount3_status different
> names, e.g. "mount.status" and "mount.status3" - or just use the same
> field for both.
>
> If two fields have the same name, the one that's registered first is the
> one whose value_string array is used in the "Add Expression" dialog box,
> so, currently, you can't get a list of the names and values for
> mount3_mountstat3 from which to select.
>
> In addition, we now don't symbolically show the error for V1 and V2
> mounts; the RFC says that the error is a "UNIX error number", and
>
> 1) any mount daemon that uses a UNIX errno that's not the same
> on all flavors of UNIX is likely to cause confusing error
> messages if you fail to mount from it;
>
> 2) EPERM, ENOENT, EIO, EACCES, ENOTDIR, and EINVAL will be the
> same on all UNIXes that ever had AT&T code in them (this
> includes the BSDs), and Linux also gives them those values on
> all architectures supported by the 2.2.18 kernel, at least
> (and I'd be *IMMENSELY* surprised if the new ones used
> different values);
>
> 3) ENAMETOOLONG is the same on BSD-derived UNIXes and Linux, and
> the AT&T UNIXes *might* have mapped it, in mount, to 63;
>
> 4) the other V3 ones are, I think, new in V3;
>
> 5) it gets shown numerically anyway, so if somebody sends a
> "non-standard" value, you at least get to see it.
>
> Using the same field for V1/V2 and V3, although it goes beyond the
> bounds of the RFC, will probably result in something that usually works
> at least as well, if not better, and rarely if ever works worse.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
