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

Trond Myklebust <trond.myklebust@fys.uio.no> Tue, 19 October 2010 21:23 UTC

Return-Path: <trond.myklebust@fys.uio.no>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95FF93A6910 for <nfsv4@core3.amsl.com>; Tue, 19 Oct 2010 14:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.41
X-Spam-Level:
X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGp4Z6tSsTce for <nfsv4@core3.amsl.com>; Tue, 19 Oct 2010 14:23:43 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id A89133A67B8 for <nfsv4@ietf.org>; Tue, 19 Oct 2010 14:23:43 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <trond.myklebust@fys.uio.no>) id 1P8JgI-0006Cl-5W for nfsv4@ietf.org; Tue, 19 Oct 2010 23:25:14 +0200
Received: from c-68-40-206-115.hsd1.mi.comcast.net ([68.40.206.115] helo=[192.168.1.29]) by mail-mx3.uio.no with esmtpsa (SSLv3:CAMELLIA256-SHA:256) user trondmy (Exim 4.69) (envelope-from <trond.myklebust@fys.uio.no>) id 1P8JgH-0000zf-DB for nfsv4@ietf.org; Tue, 19 Oct 2010 23:25:14 +0200
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: nfsv4@ietf.org
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 19 Oct 2010 17:25:10 -0400
Message-ID: <1287523510.9356.38.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 (2.30.3-1.fc13)
Content-Transfer-Encoding: 7bit
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 1045 max rcpts/h 20 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 1BBFE1E89B87FD2159247DFFA1B9659BAFCCD12E
X-UiO-SPAM-Test: remote_host: 68.40.206.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 418 max/h 7 blacklist 0 greylist 0 ratelimit 0
Subject: [nfsv4] [RFD] How to interpret empty path components in fs_locations/fs_locations_info
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Oct 2010 21:23:44 -0000

Hi,

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.

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)?

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?

Cheers
  Trond