mv/rename command and how it works on bucket backends

How do backends manage file mv or renames?

FTP and sftp both support a rename command, this is ok when using a regular filesystem in the backend, because filesystems all support a rename command natively.

Unfortunately when using a bucket backends such as Azure blob, Azure file, S3 and Google Cloud Storage, these do not support moving files in a bucket, there is no API call to rename a file.  So the solution is to perform a copy/delete operation on the backend whenever a customer performs a rename or mv command via SFTP or FTP/s.

What the logs look like?

This can be seen in the logs of a service.  A rename or mv command will appear as 2 log entries:

• Log Entry 1: The DELETE API call
• Log Entry 2: The COPY API call

An image shows what the logs look like below, this was a rename of a file /marz1.txt => /marz2.txt

Note that the execution of these API calls have an identical or nearly identical timeframe.

If you hover over one of the 'mv' operations, you can see the backend API call that was executed for that entry:

Which API call is first, copy or delete?

Although in the logs it appears as if a delete was executed first, it is actually a COPY that is executed first, then a DELETE.  The reason why the logs are ordered is for visibility to see that /marz1.txt was renamed to /marz2.txt (in the example above).

Why have 2 entries for one mv call?

Because there are 2 backend API calls, we log 2 operations.  This is to ensure that if there is a failure for a single operation it is clear which operation succeeded and which operation did not complete.  

If for example a copy will succeed but a delete fails then it is clear the delete operation was not executed, and would explain why the mv command was not completed entirely.