Re: Fusing Debian patches back into nfs-utils

["Steinar H. Gunderson" <sesse@debian.org>]

On Mon, Jun 05, 2006 at 01:13:10PM +1000, Neil Brown wrote:
> I've noticing this problem before and always shied away from it.
> While the value might be "unpredictable", someone might be depending
> on the current behaviour, and changing it could break things for some
> people while fixing things for others...
> Can you -- or anyone else -- convince me that this is really a good
> and safe thing to do?  I'm fairly open to being convince, but I don't
> feel I'm familiar enough with all the issues and would love to hear
> from someone who is.
> My particular concern is "What might it break, and how much of a
> problem could that be?" 

The biggest problem is, IMO: People expect stuff to be done as "nobody" (or,
at least uid 65534, which is mapped to "nobody" on all systems that I know).
"nobody" in Linux (as opposed to, say, Hurd) is not really someone with no
rights, but can own files etc. -- so if you had something owned by "nobody",
or "nobody" was a member of some specific group, you'd expect that to work.
Now it can easily vary between different systems, which is rather bad.

As far as I'm concerned, we've already probably had multiple instances of
this changing (from 65534 to 4294967294, when upgrading) and nobody really
noticed; I don't see the harm of changing it back to it's the same
everywhere.

> Hmm... I think the real bug here is that a '#' is treated as starting
> a comment even if it isn't at the start of a word.
> xgetc shouldn't check for '#', xgettok should.
> The kernel doesn't currently escape '#' in /proc/fs/nfs/exports so
> reading pathnames containing '#' from there will still be a problem.
> 
> So I might fix that too..... could that break anything?

Well, I think it's at least inconsistent with the man page as it's written
today; in that case, the man page should be rewritten too. Look at the
original bug report on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239230
to see the entire section.

>>  - mountd_state_directory.diff: Let the user select (via a new parameter)
>>    the path to the NFS state directory for mountd, to match the statd
>>    functionality. (If you take it in, you might want to remove the part in
>>    the manpage saying it's Debian-specific.)
> Seems pretty pointless ;-)  but that won't stop be accepting it...

It is reportedly useful for read-only /var -- people with special clustering
needs complained about the lack of such things, IIRC.

> I love getting patches that also update the man page!  Now if I can
> only train people to update ChangeLog too :-)

:-)

> Hmmm. I'm not sure I like removing blank lines just for the same of
> some silly warning - blank lines are good for readability.
> I have instead replaced them with a single ' which removes the warning
> and is almost as good as a blank.

OK, that sounds good too. I don't know why the blanks are disallowed, but
just leaving a man page with known errors wouldn't be too good either. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs