Subject: RE: [nfsv4] Stringprep Compares

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 16 Mar 2005 21:38:15 -0500

> >  Lots of folk put non-pathname contents into symlinks.  Mozilla, for
> >  example, uses symlinks as lock files.
> 
> I don't think this is mentioned anywhere in rfc3530.  If we want to allow
> arbitrary contents for symlinks, as opposed to file name paths, this needs
> to be explicit in the spec.  But I think that would be a bad idea.

If there is some restriction on the contents of a symlink than it is that
restriction that would have to be explicit.  Currently, I think the only
explicit restriction is that it has to be UTF-8.  I don't know of any other.

Whether a given string is a pathname is not determinable from the v4 spec.
Many symlinks contain ".." which is means a parent directory to UNIX but
is not defined in the v4 spec.  Similarly "/" as a delimiter is a convention
that is not part of v4. Also "~xyz" and et cetera et cetera.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Wednesday, March 16, 2005 7:05 PM
To: Nicolas Williams
Cc: [email-masked]
Subject: Re: [nfsv4] Stringprep Compares 

  Lots of folk put non-pathname contents into symlinks.  Mozilla, for
  example, uses symlinks as lock files.

I don't think this is mentioned anywhere in rfc3530.  If we want to allow
arbitrary contents for symlinks, as opposed to file name paths, this needs
to be explicit in the spec.  But I think that would be a bad idea.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Jim Rees <[email-masked]>
Date: Thu, 17 Mar 2005 07:10:49 -0500

Nico thinks link text should be opaque, but the spec currently says it's
utf-8, and as Dave pointed out, stringprep is already defined.
Normalization will be too if we fix the spec.

So I don't think we need any extra changes for symlinks.  I'm not sure why
Dave is so afraid.  Existing symlinks are no scarier than existing non-utf
file name components.