Subject: SYMLINK creation??

From: Neil Brown <[email-masked]>
Date: Thu, 18 Nov 1999 11:58:00 +1100 (EST)

While looking at atmost-once semantics for create, I thought to look
briefly at creating symlinks - only briefly because symlinks are one
thing that you can easily get atmost once semantics for, even with
NFSv2.

Imagine my surprise when I discovered that you CANNOT create symlinks
with the protocol in draft-02.  Obviously a simple oversight. (or
was it my oversight and I missed something?)

I assume that the intended operation is CREATE.

I suggest that instead of taking a "fattr4_type type" argument, it
should take a "fattr4 createattrs" argument where the object_type
attribute is required, as is possibly others (acl?).

To create a symlink, there would need to be an "linktext" attribute,
which would be required for creating symbolic links.

The existance of this attribute would neatly remove the need for the
READLINK operator, as GETATTR would then suffice.

(I almost want to use CREATE to create a hard link, where the only
attribute in the createattrs field is the filehandle to be linked, but
that would be of minimal benefit).

Related point: The LINK operation does not make it clear what happens
if the target name is already inuse.
I assume:
   If in use by a link to the source file - succeed.
   If in use by anything else - fail.

Is this true?  Should this be clearly stated?

NeilBrown

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Nov 1999 23:26:23 -0600

> was it my oversight and I missed something?)

The document is inconsistent in draft-02.  The .x definition has the 
'correct' CREATE that allows for symlink creation.  This will be
corrected in the next version of the document.

Here is the relatvant portion:

/*
 * CREATE: Create a file
 */
union createtype4 switch (nfs_ftype4 type) {
 case NF4LNK:
	 utf8string	linkdata;
 case NF4BLK:
 case NF4CHR:
	 specdata4	devdata;
 case NF4SOCK:
 case NF4FIFO:
 case NF4DIR:
 case NF4ATTRDIR:
	 void;
};

struct CREATE4args {
	/* CURRENT_FH: directory for creation */
	component4	objname;
	createtype4	objtype;
};

struct CREATE4resok {
	change_info4     cinfo;
};

union CREATE4res switch (nfsstat4 status) {
 case NFS4_OK:
	 CREATE4resok resok4;
 default:
	 void;
};

> Is this true?  Should this be clearly stated?

The description for LINK points to the RENAME description
for the appropriate semantics.  If the target is in use
and is a compatible file type, the target is removed
and the new link is created.

Spencer

---

From: Brent <[email-masked]>
Date: Wed, 17 Nov 1999 21:18:37 -0800

> I assume that the intended operation is CREATE.

Yes, the CREATE description is out of sync with the RPC
definitions in section 17.  From section 17 you'll see:

   /*
    * CREATE: Create a file
    */

   struct CREATE4args {

> READLINK operator, as GETATTR would then suffice.

Yes, my preference would be to simplify CREATE by replacing the
discriminated union with a set of file attributes.  You could
set both the symbolic link value - and any device data values
via attributes.  I also agree that READLINK is an anomaly and
linktext should be retrieved with a GETATTR.

GETATTR/SETATTR provide a good, general-purpose mechanism
for getting/setting file-related values.  I think we should
use that mechanism in preference to discriminated unions.

> that would be of minimal benefit).

Here too.  There's no need for a separate LINK operation.  We already
have a "filehandle" attribute that could be used for this purpose.
I could save a sizeable chunk of code in my server if SYMLINK and
LINKwere
just folded into CREATE.

> Is this true?  Should this be clearly stated?

Currently the definition just punts and refers to the semantics
of RENAME which are not quite the same - hence the unclear definition.
The spec should state the semantics explicitly - without referring
to RENAME (the text was copied from the v3 spec).

I think we're bound by POSIX semantics to return an EEXIST if the
link exists - whether or not it's the one we're trying to create.

	Brent

---

From: Neil Brown <[email-masked]>
Date: Thu, 18 Nov 1999 17:01:52 +1100 (EST)

> definitions in section 17.  From section 17 you'll see:

Thanks, and thanks to Spencer too -- it was my oversight.

> link exists - whether or not it's the one we're trying to create.

Yes, you're right.  This is actually depended upon for .Xauthority
locking now that I think about it some more.  It's a pity, I was hoping
LINK could be idempotent...

NeilBrown