Re: [nfsv4] [RFD] How to interpret empty path components in fs_locations/fs_locations_info

Nicolas Williams <> Tue, 19 October 2010 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91293A6860 for <>; Tue, 19 Oct 2010 14:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CEGhE9IIGMjC for <>; Tue, 19 Oct 2010 14:52:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F23FE3A67B8 for <>; Tue, 19 Oct 2010 14:52:13 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9JLreTG004296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Oct 2010 21:53:41 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9JIhjDC016733; Tue, 19 Oct 2010 21:53:39 GMT
Received: from by with ESMTP id 703664581287525215; Tue, 19 Oct 2010 14:53:35 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Oct 2010 14:53:35 -0700
Date: Tue, 19 Oct 2010 16:53:31 -0500
From: Nicolas Williams <>
To: Trond Myklebust <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
Subject: Re: [nfsv4] [RFD] How to interpret empty path components in fs_locations/fs_locations_info
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Oct 2010 21:52:15 -0000

On Tue, Oct 19, 2010 at 05:25:10PM -0400, Trond Myklebust wrote:
> An issue was raised in the fedfs concall last week concerning how to
> represent the root directory in fs_locations/fs_locations_info.
> As near as the group on the call could determine, there are 2 possible
> representations, neither of which appear to be explicitly forbidden by
> the spec:
>      1. The server may specify a 'pathname4' entry with no components
>      2. The server may specify a 'pathname4' with a single component of
>         length 0.

I believe only (1) makes sense.  The root path has no components.  We
happen to write that as "/" in Unix-ish systems, but that's just because
"" would be rather confusable, whereas a single '/' is not.

> The following question then arose: if we allow representations of type
> 2. above, then presumably we must also allow for the fact that the
> server may embed zero-length components anywhere in the 'pathname4'
> array. We assume that the interpretation would then be the same as a
> POSIX path of the form /a/b/////c (i.e. the path should be interpreted
> as equivalent to /a/b/c)?

POSIX requires that /a/b/////c be the same as /a/b/c.  IIRC POSIX does
not require that /a, //a, and ///a all be the same -- it allows special
semantics for double slashes at the root of a path (IIRC this was for an
Appolo Domain feature) -- but we have no need for this.

If a POSIX client's user could never write a path like /a/b/////c with
actual empty components, then it'd be bad to allow such paths to exist.
Therefore servers must not allow them.  Which in turn makes (2) suspect,
though not outright wrong -- we need a convention, and in a pinch (2)
would do.

But if we can't allow empty components in paths with more than one
component, why not simply reserve all empty components and be done?
Then (1) is clearly the best choice.

> The question we'd like to put to the list is therefore whether or not
> clients should be required to deal with this, or whether the spec should
> be amended to discourage (or even forbid) servers from using this kind
> of representation for a path?

Servers which allow for empty components make impossible for POSIX
clients to get at filesystem objects with such paths.  That is what I'd
consider a Bad Thing.  Unless there exist major OSes which do allow
empty components, then I think empty components must be disallowed.

Q: Can any OS with a hierarchical filesystem structure have empty path

POSIX doesn't allow it.  I don't think Windows allows it (as with Appolo
Domain, a leading double [back]slash denotes a UNC).  I doubt MacOS X
allows it either.  If no major OS allows it then there's no reason to
allow NFSv4 servers to allow it.  Even if there were a major OS that
allows empty components, the spec should at least describe issues
relating to them and say they are at least NOT RECOMMENDED if not
outright MUST NOT.