On Tue, 5 Oct 1999, Martin Blapp wrote:
> 1. Parsing a NFS-Path with directory-components which include ':'
> or '@' in their path gets difficult. To support it,
> mount_nfs(8) and umount(8) have to handle several exceptions:
>
> - nfs-server:/some@stupid/p@th
> - some:stu:pid/@pa:th@nfsserver
>
> The chars ':' and '@' are allowed in pathnames.
You could parse these with some sort of iterative parser (parse it one
way, if it doesn't work parse it another way), but that would be tricky to
code and could have some interesting security implications.
>
> 2. 'nfs-server:/some/path' and '/some/path@nfsserver' should be
> equal. But umount(8) does not recognize them as equal. You are
> obliged to give the exact variant you had choosen before.
I find that reasonable.
>
> 3. Is is really difficult to recognise whether the nfs-path should
> be relative or absolute. According to RFC 2224 and RFC 2054,
> NFS does allow absolute _AND_ relative NFS paths. The relative
> path depends on where the public filehandle of the nfs-server is
> stored.
>
> If we allow both variants with ':' and '@' as delimitors,
> there may be a lot of complicated situations as described
> in (1).
>
> I propose to remove the '@' feature because of the above reasons. It is
>
> much easier to fix our userland mount(8) and umount(8) commands to
> handle the different situations properly as described in the RFC.
If you want to do this, I suggest a round of releases that have mount
complain about the @ syntax before you kill it. POLA, you know.
A complaint such as:
WARNING: path@server syntax is deprecated, use server:path
would be sufficient.
Doug White | FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
