Subject: Re: [nfsv4] Stringprep Compares

From: Jim Rees <[email-masked]>
Date: Wed, 16 Mar 2005 19:04:39 -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.

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Mar 2005 18:07:18 -0600

> to be explicit in the spec.  But I think that would be a bad idea.

Oh, but RFC3530 is *quite* clear on this.

LOOKUP and OPEN don't traverse symlinks, and READLINK's description
explicitly says that symlink contents is opaque to the server:

   READLINK reads the data associated with a symbolic link.  The data is
   a UTF-8 string that is opaque to the server.  That is, whether
   created by an NFS client or created locally on the server, the data
   in a symbolic link is not interpreted when created, but is simply
   stored.

and:

   A symbolic link is nominally a pointer to another file.  The data is
   not necessarily interpreted by the server, just stored in the file.
   It is possible for a client implementation to store a path name that
   is not meaningful to the server operating system in a symbolic link.
   A READLINK operation returns the data to the client for
   interpretation. If different implementations want to share access to
   symbolic links, then they must agree on the interpretation of the
   data in the symbolic link.

and I'm sure there's more evidence of this elsewhere in there.

Nico
--