Subject: RE: SYMLINK creation??

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 19 Nov 1999 08:03:18 -0800

> Neil Brown wrote:
 
> > 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.
> 
> 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.

I don't see that READLINK is an anomaly any more than READDIR 
or READ are.  Files have contents as well as attributes
and the text of a symlink seems more like the contents
than an attribute, at least to me.  Most file systems
implement them that way, too.  You could make an argument
than READ and READLINK be merged to avoid one op, but 
there would have to be a fairly pressing reason to do it
at this late stage.

> 
> 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.

Doing this would add a lot of complexity to an already
complicated attribute mechanism.  Right now we have attributes
that are read-only and attributes that you can set.  This
would add a third class of attributes: those that you can
set in CREATE and get but not set via SETATTR (at least if 
we don't want to put new semantic demands on filesystems).

Futher, there are rules that would have to be documented
and implemented about what attributes are required on a
CREATE:

     You have to specify the type.

     If the type is LINK, you have to specify linktext

     If the type isn't LINK, you can't specify linktext

     If the type is a special file, you have to specify
     the device info.

     If the type isn't a special file, you can't specify
     the specify the device info.

     You can, in addition, specify any writable attribute.

Except for the last, the discrimnated union documents this
perfectly.  I would add an attribute array in addition to
the discriminated union to allow additional writable attributes
to be specified.

I also note that CREATE-EXCLUSIVE seems to have gone away.
In fact, I have heard people complain about the fact that
they can't do a MKDIR wihout the possibility of a spurious
EEXIST.  This is a real problem and I would hate to have 
to have a problem which existed in v2 and was partly solved
for v3 (for regular files), which I thought was going to 
be fixed for v4 pushed off to some minor version. 

CREATE-EXCLUSIVE for symlinks and special files (if that 
is necessary) would require either a special SETATTR that
could set attributes not ordinarily setable or a 
CREATE_COMPLETE op that allowed a createtype4 to be
specified on a existing (actually partially-created)
file.

> > (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).
> 
> Here too.  There's no need for a separate LINK operation.  We already
> have a "filehandle" attribute that could be used for this purpose.

So now we have some more rules:

     You can specify the handle attribute (not ordinarily
     settable) for CREATE.

     If you do specify the handle attribute, you can't specify 
     any other attribute, including type, which is otherwise
     required for CREATE.

LINK and CREATE are not the same and merging them just 
confuses things.  CREATE creates a new object and LINK
creates a new name for an existing object.  The implementations
are very different.  (e.g. they are different VOP's whose
embodiments do different things initially and then, at
some level, call some common directory management code).
I would hate to have two different operation smerged 
together just so you could have some complicated code
buried in CREATE which analyzed an attribute bit map to 
figure out what you are really doing.  The client knows
he is doing a link and the server fs as to know as well.  
The simplest way to pass that information over the wire 
and through the nfs server code is to say "Hey you, do 
a LINK".

> I could save a sizeable chunk of code in my server if SYMLINK and
> LINKwere
> just folded into CREATE.

Just adds a lot of code to mine and makes CREATE even more
impenetrable then it is already.

SYMLINK already is folded into CREATE, which it should be.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 19 Nov 1999 08:35:36 -0800 (PST)

> there would have to be a fairly pressing reason to do it

I agree. We could take this to the extreme and claim that file data and 
directory entries are attributes and do every read operation via GETATTR, and
every write operation via SETATTR. 

Personally, I like the opposite extreme, and claim that every file type
deserves, where applicable, its own operation to read the file type specific
content. I.e. READ, READLINK, READDIR, and READSPECDATA, the latter not being
in the spec right now.

But there is no pressing reason for READSPECDATA at this stage.

Another thing I'd have liked to see, which I'm sure I mention once or twice in
last 3 years, was proper support for non-idempotent exclusive CREATE of
non-regular files. But this isn't pressing either. Since we've reached
consensus on minor versioning, there's a plethora of stuff that can be
considered later.

BTW, Beepy said something at the D.C. WG meeting about declaring a feature
freeze on the specification, except for the open items that were open as of
the D.C. ietf meeting.

	-mre

---

From: Neil Brown <[email-masked]>
Date: Mon, 22 Nov 1999 16:27:20 +1100 (EST)

> there would have to be a fairly pressing reason to do it

On reflecting, the anomaly that I see is between symlinks and
device-special files.
I cannot see any important difference between
   GETATTR(rawdev) and READLINK
They both get some read-only information about a non-file object that
has meaning only to the client.
Obviously there is not a pressing need to change it, but it does seem
a bit odd.

> the discriminated union to allow additional writable attributes

I would second the addition of an attribute array - atleast for
assigning initial permissions to obejcts.

> specified on a existing (actually partially-created)

Why not simply specify all create-time attributes, and a create
verifier, all at create time.  If a particular filesystem on a
particular server cannot store all the attributes, and the share-locks, and
the verifier atomically, then maybe there could be a per-filesystem
attribute that lists attributes that need to be set after a
verified-exclusive create.
I suspect that most filesystems could store the verifier safely.  A
unix server could:
   - create object in a private directory, open it, lock it
   - record inode-number-to-verifier mapping in some log file
   - link it to the desired name, and then unlink from private dir.
   If the link fails with EEXIST, check the inode-number of the
   existing file in the log to see what verifier it had. 

That way, servers that can support verified exclusive create easily
can do so without needing the extra SETATTR, and servers that cannot
can indicate by some attribute either that it isn't supported at all,
or that an extra SETATTR is required.  This seems to be the V4 way to
do things - have attributes that describe server behaviour instead of
having the client guess.
(I assume that the point of GUARDED is that some server/filesystems
cannot support EXCLUSIVE - the client trys one and falls back to the
other.  Instead, the server should tell the client how much it can
guarantee).

NeilBrown