rename / unlink bug

[jti-lanl]

If you delete a renamed file, you get a "no such file" error. This is because the post xattr on the renamed file still refers to the original MDFS path.

stat_xattrs() should not always update the mdfs-path from the post xattr.

There is a secondary "bug" which is preventing the first one from having the worst consequences. The place in expand_path_info() where it would test for PI_EXPANDED and skip out early has been commented out. (My doing, long ago.) Therefore, in trash_truncate() -> expand_trash_info() -> expand_path_info(), we recompute PathInfo.post.md_path for renamed files, instead of using the wrong one we got from the xattrs.

This means that the trashing is done with the correct MD file. That's why we DO NOT have the following bug:

$ echo testing > /marfs/file1
$ mv /marfs/file1  /marfs/file2   # POST xattr still indicates "/marfs/file1"
$ echo foo > /marfs_file1
$ rm /marfs/file2                 # delete /marfs/file1

But we do still have subtle problems:

$ echo testing > /marfs/file1
$ mv /marfs/file1  /marfs/file2
$ rm /marfs/file2
rm: cannot remove `/marfs/file2': No such file or directory
$ ls /marfs/file2
/marfs/file2

And

$ echo testing > /marfs/file1
$ mv /marfs/file1  /marfs/file2
$ ln -s blah /marfs/file1
$ rm /marfs/file2        # this will try to lgetxattr() on the symlink
rm: cannot remove `/marfs/file2': Operation not permitted

The situation appears "safe", for any repos we deploy.

• trash gets the correct chunkinfo for multi-files
• trash has correct size, etc.
• trash "companion" refers to correct name

This means that GC of file2 will not destroy anything belonging to the new file1.

HOWEVER, it's possible that MarFS on top of a standard file-system (i.e. DIRECT mode) might show the bad behavior where file1 is deleted.

FIXING

• rename() should NOT be fixed to correctly save the updated MD-path in POST. Instead, stat_xattrs() should skip overwriting POST.md_path. A new arg could be added, so that callers who wanted it, could force it to overwrite.

• expand_path_info() should revert to skipping out if already expanded. test this extensively.

• Update the object version from 1.7 to 1.8, so we can attempt to mitigate, with old trash, etc, if we discover problems.

[jti-lanl]

This is fixed in the "rdma" branch. Did all the "FIXING" things.