I was told in the past, as well, that UM can handle moves/renames. It simply isn't true - or at least I have never seen an instance where it has worked. Theoretically, there are several triggers it could use as the db stores an MD5 hash (not sure how it gets this, whether it calculates it which seems unlikely due the the network load, or relies on the remote fs to supply it) and the inode number (presumably of the first block, but not sure how this works for non unix-like fs's but certainly all my media is on an NTFS share and these attributes are filled out fine!)
I was told it uses the inode. But in practice, if you rename a file or move it, UM finds it as a new file in the new location (you can see this in the UM log) and in the admin site, if you click the option to show missing files, you will see the old file in the old location. This not only prevents LMCE from treating a file as a continuous, discrete object in its logic, but also ensures that the database gets messy unless you scrupulously clean up or only use the admin site to do the moves/renames. That's a thought - you didn't think I mean via the admin site did you? Of course that works, it would be pointless otherwise. I'm talking about using any other method to move/rename files, LMCE terminal, Windows Explorer, NAS management tool. It is blinkered to say that file management should only ever be done within the admin console - there are many instances where this simply isn't practical or even possible
On the same subject, duplicating files is another difficult one. If you use only the MD5 hash to uniquely identify a file, then duplicating will screw up the logic as both files will match. This seems to indicate that a combination of MD5 hash and 'inode' need to be combined in the logic to complete it.
If a "new" file is encountered that has the same MD5 and inode as an "existing" file -> check does the "existing" file still exist? If no, then action was a move or rename -> update existing db record; else error?
If a "new" file is encountered that has the same MD5 but different inode as an "existing" file -> check does the "existing" file still exist? If yes, then action was a copy -> create new db record, and copy old db record's attributes over; else error? (although this could potentially still be a move/rename, just between different filesystems)