AnsweredAssumed Answered

Cannot rename across volumes, falling back on copy/delete semantics

Question asked by john.humphreys on Mar 7, 2018
Latest reply on Mar 9, 2018 by john.humphreys

I have a Spark job where I was trying to rename MapR-FS files across volumes, and it gave me this INFO log:

18/03/07 12:52:10 INFO MapRFileSystem: Cannot rename across volumes, falling back
on copy/delete semantics

A rename would be an atomic operation that produced no extra files in the destination area.  Can someone confirm to me that this fallback mechanism is implemented similarly? I.e. if it has any work-space for its files, its external to the target directory?

Outcomes