[PVFS-developers] libpvfs: rename bug

[Rob Ross]

Hi Don,

This particular patch doesn't apply cleanly any more, but I've
hand-patched it (hopefully not screwing anything new up!).

The issue that you bring up with the kernel side of things shouldn't be an 
issue with the create part of the patch, as I see it.

Thanks much for the patch; it's in CVS now.

Regards,

Rob

On Tue, 2 Mar 2004, Porter Don wrote:

> So, where do these values come from...
> 
> library: In pvfs_detect, it calls MGR_ACCESS, which _should_ return ENOENT
> but store the fs_ino in the ack structure.  It instead puts in a -1 for some
> reason I don't understand.  This value is then passed in to the MGR_OPEN
> call that creates the file, which is dutifully written to disk without
> question.
> 
> kernel: in (k)pvfs_v1_xfer.c: create_pvfs_file, line 382/385:
> 
> 	req.req.open.meta.fs_ino = 0; /* probably needs to be set... */
> 
> In a way, this shows that it isn't all that important of a field.  I would
> say just scrap it if we are filling in zeros, but I think that it is needed
> for pvfs_rename to work safely :).  But maybe there is even a better way to
> do that.  
> 
> David Metheny and I figured out how to change mgr:do_access to return the
> right fs_ino instead of -1 (attached), but I don't know enough about the
> kernel code to know if there is even a good way to get that in the create
> call other than to do an access call.  Is that stored somewhere?