Re: LINK and RENAME issues

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Brent (brent@eng.sun.com)
Date: 11/04/99-10:44:47 PM Z 

Message-ID: <382260BF.EA351A10@eng.sun.com>
Date: Thu, 04 Nov 1999 20:44:47 -0800
From: Brent <brent@eng.sun.com>
Subject: Re: LINK and RENAME issues

Mike Eisler wrote:
> The arguments to the LINK and RENAME operations both contain a pair of
> fields like:
> 
>            nfs_fh4         dir;
>            component4      newname;
> 
> The field 'dir' is the file handle of the target directory. The file
> handle of the source directory, or if the case of LINK, the source
> file, is passed to LINK and RENAME via a previous PUT*, RESTOREFH,
> LOOKUP, LOOKUPP, or OPEN (and any other operation I've overlooked at
> places a file handle into the compound operation stream).
> 
> This makes target directories second class citizens.


I agree, that does seem like a wart.

I'd like to propose a simpler option.  Instead of adding
a new operation, why not just define the second LINK/RENAME
filehandle as the saved filehandle ?

So you get:

	SYNOPSIS
		(cfh), oldname, (savefh), newname -> source_change_info

or

     struct RENAME4args {
             /* CURRENT_FH: source directory */
             component4       oldname;
             /* SAVED_FH: target directory */
             component4       newname;
     };

It all works the same as "restorefh_targ" but without a new op.

	Brent

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:51 AM Z CST