From patchwork Mon Jun 9 21:51:52 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 357630 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id E25C61400AB for ; Tue, 10 Jun 2014 07:55:29 +1000 (EST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s59LtPmb011813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jun 2014 21:55:26 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s59LtOPr005337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 21:55:24 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Wu7UE-0003OX-TW; Mon, 09 Jun 2014 14:52:14 -0700 Received: from ucsinet22.oracle.com ([156.151.31.94]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1Wu7Ty-0003KX-AQ for fedfs-utils-devel@oss.oracle.com; Mon, 09 Jun 2014 14:51:58 -0700 Received: from aserp1020.oracle.com (aserp1020.oracle.com [141.146.126.67]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s59LpvVO009856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Jun 2014 21:51:57 GMT Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by aserp1020.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s59LpuYR027615 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 9 Jun 2014 21:51:56 GMT Authentication-Results: aserp1020.oracle.com; dkim=pass reason="2048-bit key" header.d=gmail.com header.i=@gmail.com header.b=tlzifN1C Received: by mail-ie0-f172.google.com with SMTP id lx4so3135503iec.31 for ; Mon, 09 Jun 2014 14:51:56 -0700 (PDT) X-Received: by 10.50.118.102 with SMTP id kl6mr41534607igb.7.1402350715982; Mon, 09 Jun 2014 14:51:55 -0700 (PDT) Received: from seurat.1015granger.net ([2604:8800:100:81fc:20c:29ff:fe44:ec31]) by mx.google.com with ESMTPSA id m1sm59608313ige.22.2014.06.09.14.51.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jun 2014 14:51:55 -0700 (PDT) To: fedfs-utils-devel@oss.oracle.com From: Chuck Lever Date: Mon, 09 Jun 2014 17:51:52 -0400 Message-ID: <20140609213155.3379.56192.stgit@seurat.1015granger.net> User-Agent: StGit/0.16 MIME-Version: 1.0 X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=209.85.223.172 ct-class=R5 ct-vol1=-96 ct-vol2=8 ct-vol3=7 ct-risk=41 ct-spam1=62 ct-spam2=7 ct-bulk=6 rcpts=1 size=2130 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=YMWml32x c=1 sm=1 tr=0 a=RPZgViSN43jj7cy/UnIhow==:117 a=dzsqy3y4QnMA:10 a=V641hV_Sm50A:10 a=dPGociXpb70A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=yPCof4ZbAAAA:8 a=Lb1rMZzfAAAA:8 a=1XWaLZrsAAAA:8 a=omOdbC7AAAAA:8 a=OK-8mIdLAAAA:8 a=48vgC7mUAAAA:8 a=0XI3lubMxXJyq2x-NJ4A:9 a=hOHItVa5XRI-0Lyx:21 a=WskHKB1qx3k5duWJ:21 a=QEXdDO2ut3YA:10 a=7DSvI1NPTFQA:10 X-Sendmail-CT-RefID: str=0001.0A090205.53962C7C.00B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Sendmail-CT-Classification: not spam Subject: [fedfs-utils] [PATCH] libnsdb: NFS URI is incorrect when storing FSLs in NSDBs X-BeenThere: fedfs-utils-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fedfs-utils Developers List-Id: fedfs-utils Developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fedfs-utils-devel-bounces@oss.oracle.com Errors-To: fedfs-utils-devel-bounces@oss.oracle.com X-Source-IP: acsinet21.oracle.com [141.146.126.237] Ditang Chen says: > I tested in Fedora20, when junction type is nfs-fedfs, the nfsref > cannot resolve FSN if the export path is "/". > > # nfsref -d --type=nfs-fedfs add /.domainroot/example.net/s2 server2.example.net / > ... > nfsref: nsdb_normalize_path: result = '/' > nfsref: nsdb_count_components: length = 4, count = 0, path = '/' > nfsref: nsdb_alloc_zero_component_pathname: Zero-component pathname > nfsref: nsdb_construct_nfsuri: NFS URI: nfs://Server2.example.net/ > ... > > # nfsref -d lookup s2/ > .. > nfsref: nsdb_parse_nfs_uri: parsing 'nfs://server2.example.net/' > nfsref: nsdb_uri_pathname_to_path_array: NFS URI has short pathname component > nfsref: nsdb_resolve_fsn_parse_entry: parsing failed: FEDFS_ERR_BADNAME > nfsref: nfsref_lookup_resolve_fsn: Failed to resolve FSN 5f4bace9-14b3-4626-8d39-4b0 > ... For a server pathname of "/", nsdb_construct_nfsuri() was constructing an NFS URI with just a single terminating /, which is incorrect according to section 2.8.1.2 of: http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/ Then "nfsref" is storing the incorrect URI in the NSDB. Fixes: 750fdf4bba4f5d4880ce7ad5b56451bd771cc3e2 Reported-by: Ditang Chen Signed-off-by: Chuck Lever --- Hi Ditang- This approach is more verbose, but doesn't hard-code the URI path segment separator character. src/libnsdb/path.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/libnsdb/path.c b/src/libnsdb/path.c index c58dc8979848..298a029ba561 100644 --- a/src/libnsdb/path.c +++ b/src/libnsdb/path.c @@ -635,6 +635,15 @@ nsdb_path_array_to_uri_pathname(char * const *path_array, UriUriA *uri) return FEDFS_ERR_SVRFAULT; result = pos; + /* Zero-component pathname? */ + if (path_array[0] == NULL) { + pos->next = nsdb_new_uri_path_segment(""); + if (pos->next == NULL) { + status = FEDFS_ERR_SVRFAULT; + goto out_err; + } + } + length = 0; for (i = 0; path_array[i] != NULL; i++) { component = path_array[i];