[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
- [nfsv4] [RFD] How to interpret empty path compone… Trond Myklebust
- Re: [nfsv4] [RFD] How to interpret empty path com… Nicolas Williams
- Re: [nfsv4] [RFD] How to interpret empty path com… Nicolas Williams
- Re: [nfsv4] [RFD] How to interpret empty path com… david.noveck
- Re: [nfsv4] [RFD] How to interpret empty path com… Trond Myklebust
- Re: [nfsv4] [RFD] How to interpret empty path com… david.noveck