Correct a recent update for calling acPostProcForModifyAVUMetadata to
test for positive values too, else it's never called for `imeta addw`.

The recently added test in rsModAVUMetadata.c was not right in all
cases since chlAddAVUMetadataWild returns the number of data objects
that were modified but we had it only calling the post-processing rule
if the return value was zero.  Error codes are always negative and
sometimes positive.

Noticed and fix provided by Dennis Roberts of iPlant. Thanks!



git-svn-id: svn://irodssvn.ucsd.edu/trunk@5593 ea137bd6-aa86-47b6-b90d-b101d9f19a90
Document a problem in imv where moving and renaming in a single imv
command is not always allowed.  This is Bugzilla item 165 (submitted
recently).

An example is 
imv file1 coll1/file2

This will work fine if there is no file1 in the source collection, but
will fail if there is, giving the error CAT_NAME_EXISTS_AS_DATAOBJ.

The reason for this that the move functionality is handled internally
as separate functions for moving and renaming.  The mvUtil /
rsDataObjRename code performs a rename, or a move, or both.  So in
this case that logic does a rename followed by a move.  And that will
fail if there's a conflicting data-object name in the source
directory.

Of course, it would be possible to handle this case via some
additional checks, renaming to an intermediate form, doing the move,
and then doing another rename, but I think that would require too many
additions and changes and so presents too much risk for the benefit.

So I've added some text in the imv help text to explain this.  Users
can handle this case manually and, hopefully, the help text will make
it less confusing.  It is still odd though.


git-svn-id: svn://irodssvn.ucsd.edu/trunk@5594 ea137bd6-aa86-47b6-b90d-b101d9f19a90