should vn_fullpath1() ever return a path with "." in it?

Rick Macklem rmacklem at uoguelph.ca
Thu Feb 28 02:59:29 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getcwd.patch
Type: text/x-patch
Size: 672 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20130227/65580cbb/attachment.bin>


More information about the freebsd-fs mailing list