From owner-freebsd-fs@FreeBSD.ORG Thu Feb 28 02:59:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58506410; Thu, 28 Feb 2013 02:59:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E84E73A4; Thu, 28 Feb 2013 02:59:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACTHLlGDaFvO/2dsb2JhbABFhk+4e4JlgRNzgiYjVkQZAgRVBogmrweSZ45gGRsHgi2BEwOIaoY8hxuJY4cHgyaCCQ X-IronPort-AV: E=Sophos;i="4.84,752,1355115600"; d="scan'208";a="18641552" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Feb 2013 21:59:22 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 08FFCB3F0D; Wed, 27 Feb 2013 21:59:22 -0500 (EST) Date: Wed, 27 Feb 2013 21:59:22 -0500 (EST) From: Rick Macklem To: FreeBSD Filesystems Message-ID: <707174204.3391839.1362020362019.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <860349954.3391816.1362020304865.JavaMail.root@erie.cs.uoguelph.ca> Subject: should vn_fullpath1() ever return a path with "." in it? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3391838_1284162422.1362020362017" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Sergey Kandaurov , Kostik Belousov X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:59:29 -0000 ------=_Part_3391838_1284162422.1362020362017 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Sergey Kandaurov reported a problem where getcwd() returns a path with "/./" imbedded in it for an NFSv4 mount. This is caused by a mount point crossing on the server when at the server's root because vn_fullpath1() uses VV_ROOT to spot mount point crossings. The current workaround is to use the sysctls: debug.disablegetcwd=1 debug.disablefullpath=1 However, it would be nice to fix this when vn_fullpath1() is being used. A simple fix is to have vn_fullpath1() fail when it finds "." as a directory match in the path. When vn_fullpath1() fails, the syscalls fail and that allows the libc algorithm to be used (which works for this case because it doesn't depend on VV_ROOT being set, etc). So, I am wondering if a patch (I have attached one) that makes vn_fullpath1() fail when it matches "." will break anything else? (I don't think so, since the code checks for VV_ROOT in the loop above the check for a match of ".", but I am not sure?) Thanks for any input w.r.t. this, rick ------=_Part_3391838_1284162422.1362020362017 Content-Type: text/x-patch; name=getcwd.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=getcwd.patch LS0tIGtlcm4vdmZzX2NhY2hlLmMuc2F2CTIwMTMtMDItMjcgMjA6NDQ6NDIuMDAwMDAwMDAwIC0w NTAwCisrKyBrZXJuL3Zmc19jYWNoZS5jCTIwMTMtMDItMjcgMjE6MTA6MzkuMDAwMDAwMDAwIC0w NTAwCkBAIC0xMzMzLDYgKzEzMzMsMjAgQEAgdm5fZnVsbHBhdGgxKHN0cnVjdCB0aHJlYWQgKnRk LCBzdHJ1Y3QgdgogCQkJICAgIHN0YXJ0dnAsIE5VTEwsIDAsIDApOwogCQkJYnJlYWs7CiAJCX0K KwkJaWYgKGJ1ZltidWZsZW5dID09ICcuJyAmJiAoYnVmW2J1ZmxlbiArIDFdID09ICdcMCcgfHwK KwkJICAgIGJ1ZltidWZsZW4gKyAxXSA9PSAnLycpKSB7CisJCQkvKgorCQkJICogRmFpbCBpZiBp dCBtYXRjaGVkICIuIi4gVGhpcyBzaG91bGQgb25seSBoYXBwZW4KKwkJCSAqIGZvciBORlN2NCBt b3VudHMgdGhhdCBjcm9zcyBzZXJ2ZXIgbW91bnQgcG9pbnRzLgorCQkJICovCisJCQlDQUNIRV9S VU5MT0NLKCk7CisJCQl2cmVsZSh2cCk7CisJCQludW1mdWxscGF0aGZhaWwxKys7CisJCQllcnJv ciA9IEVOT0VOVDsKKwkJCVNEVF9QUk9CRSh2ZnMsIG5hbWVjYWNoZSwgZnVsbHBhdGgsIHJldHVy biwKKwkJCSAgICBlcnJvciwgdnAsIE5VTEwsIDAsIDApOworCQkJYnJlYWs7CisJCX0KIAkJYnVm Wy0tYnVmbGVuXSA9ICcvJzsKIAkJc2xhc2hfcHJlZml4ZWQgPSAxOwogCX0K ------=_Part_3391838_1284162422.1362020362017--