User Share / Mover oddities

This is an inherent quirk of the underlying Linux system in that if it thinks the source and target are on the same mount point it implements move by first attempting a simple rename (for speed) and only if it fails does a copy/delete get run.   Since this is fundamental Linux behavior I am not sure that there is anything Unraid can do about it.   Mover is specifically written to leave files for a share with Use Cache = No alone even if they exist on the cache as there is a Use Case for that behaviour.   A possible solution might be to introduce yet another option for the Use Cache setting, but users already have problems with the number of options already allowed for.

 

The ‘workaround’ is to either use a copy/delete operation yourself or to make the target folder have a Use Cache=Yes setting so that mover will later transfer the file to the array.

 

You often see this behaviour when using a docker container to automate downloads.   If you set the drive mappings for the container to have different internal mount points then the version of Linux inside the container will implement its own ‘move’ as a copy/delete so the issue does not arise at the Unraid level.   However it is still often more convenient to simply set the target to a location set with Use Cache = Yes.
 

To force the copy/delete behaviour you can make the move operation be ...

 

'move /mnt/user/Downloads/foo /mnt/user0/Books/’

Changed Status to Closed

Changed Priority to Other