Re: kern/45425 (how to restore traditional unix behaviour for slashes on the end of pathnames)

["Greg A. Woods" <woods%weird.com@localhost>]

The following reply was made to PR kern/45425; it has been noted by GNATS.

From: "Greg A. Woods" <woods%weird.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: dholland%NetBSD.org@localhost
Subject: Re: kern/45425 (how to restore traditional unix behaviour for slashes 
on the end of pathnames)
Date: Mon, 07 Oct 2013 12:42:48 -0700

 At Mon,  7 Oct 2013 07:46:46 +0000 (UTC), dholland%NetBSD.org@localhost wrote:
 Subject: Re: kern/45425 (how to restore traditional unix behaviour for slas=
 hes on the end of pathnames)
 >=20
 > Synopsis: how to restore traditional unix behaviour for slashes on the en=
 d of pathnames
 >=20
 > State-Changed-From-To: open->closed
 > State-Changed-By: dholland%NetBSD.org@localhost
 > State-Changed-When: Mon, 07 Oct 2013 07:46:46 +0000
 > State-Changed-Why:
 > the behavior described is not incorrect and the proposed alternative
 > *is* incorrect.
 
 So, are you saying Ken Thompson's original unix namei algorithm is
 actually "incorrect" after all these years?  Perhaps you could explain
 that to him?
 
 Way back when we were still discussing this in a more sensible fashion
 you made a remark that I asked for clarification about, but there's no
 reply from you addressing that specific issue in the PR and I don't have
 a private reply in my e-mail either.
 
 I asked you to address the issue of why you think my patch will break a
 specific behaviour, which you gave an example of, and which I then
 showed that (to the best of my understanding of your example) my change
 would not break or change in any way.
 
 Your only answer was a cryptic, and so far as I can tell meaningless,
 statement about the difference between "mkdir foo/" at the user level
 vs. the kernel's 'rmdir("foo/")' behaviour.
 
 With my change both mkdir("foo/") and rmdir("foo/") work just fine, and
 of course that means the user level also has the same fine behaviour.
 
 I think maybe you should actually build a kernel with my patch and try
 it out for yourself so that you can see what it actually changes, and
 what it does not change.  (and perhaps also boot v7 in emulation and
 compare -- there should also be an original unix(tm) kernel with symlink
 support somewhere too, but I can't say for sure I know of a specific one
 to try)
 
 I've shown several examples of how my patch does not affect any existing
 tools, and I've given the claim that it doesn't adversely affect a much
 wider user population either.  Indeed I've used kernels with my patch
 exclusively for over a decade now and I've never once had to patch or
 fix any user-level code of any kind to keep it working correctly.
 
 I've shown that the only really visible change of behaviour caused by my
 patch has to do with symlinks and how one specific tool (and by
 extension possibly other similar tools) shows a different user-level
 interpretation of underlying filesystem structure depending on whether
 the reference to that structure is through a symlink or not.  I've
 further shown how that tool could be fixed to continue to provide a
 consistent user-level interpretation of the actual underlying structure.
 Indeed as far as I can tell my patch actually makes the user-level
 experience more consistent.
 
 I also still believe the biggest problems anyone has with understanding
 the semantics of slashes in pathnames has to do with the way _some_
 applications interpret pathnames _some_ of the time; vs. the underlying
 way the kernel might interpret a pathname.  See the opening two
 paragraphs of the PR again.  This patch is about the kernel and its
 algorithm for de-composing a pathname into its components and mapping
 that pathname onto the actual underlying filesystem structure.
 
 Meanwhile buried in the depths of tech-userlevel are examples of
 problems actually caused by the BSD behaviour which I fix with my patch
 by reverting to traditional unix behaviour.
 
 I feel strongly enough about this issue that I believe the original unix
 algorithm should be preserved in at least one kernel being maintained on
 an ongoing basis so that its true elegance can be actually appreciated
 by those interested in working with it.  This is one of those things
 where even the original unix can still teach people something valuable
 about certain aspects of file-systems.  Perhaps NetBSD isn't that
 kernel, but I would sure like it to be.  If figuring out how to wrap
 this change into either an #ifdef and/or sysctl() would help you in
 particular greet it with slightly less personal animosity then I'd be
 happy to modify it.
 
 --=20
                                                Greg A. Woods
 
 +1 250 762-7675           <gwoods%acm.org@localhost>     RoboHack 
<woods%robohack.ca@localhost>
 Planix, Inc. <woods%planix.com@localhost>    Avoncote Farm 
<greg.a.woods%avoncote.ca@localhost>