Manual Import, Move, Files actually copied then deleted

SONARR Ver 2.0.0.5338:
MONO Ver 5.18.0.240:
Synology DSM 6.2.2-24922 Update 3:
Debug Log https://pastebin.com/9b2igNgu

When I run a manual import, in this case a 200GB Season Rip on Battlestar Galactica (2014), I select the MOVE option, however Sonarr does not actually ‘move’ the file and rename. Rather :

  1. “.backup” file with the original name shows up in the original import directory,
  2. The new filename version is copied into the show directory with a “.partial~” extension. You can see the file size of this increase
  3. The .partial~ is then removed for the file name and the original file in the import directory is deleted.

This is rather a pain for large import file sizes, it takes a very long time to duplicate so much data rather than just renaming and doing a move operation which would be instant.

Is there a reason Sonarr is not using a file system move operation?
Is this only something happening on Synology?

Thanks for any feedback

It’ll do that when copying across mounts or when dealing with network mounts. This is to deal with some issues with mono in some file system combinations that lead to truncated files.

Thanks for that info.

I can confirm in my case that the folder I am importing from “Download Temp” is on the same volume as the move to directory “TV Shows”.

LS of directory https://pastebin.com/DmHHhhnt

Could it be because on synology, these folders are set up as different shares? Does Sonarr see these folders in Volume2 as shares rather than a directory?

I currently use Sonarr that is from the Community Applications section. Could it be worth trying in a docker container to work around the copy move issue?

the synology shares are seen as different volumes so it would copy across.

if you referenced them as /volume2/DownloadTemp and /volume2/TV Shows instead of their share names then it should be able to move them

you could use docker but with your current folder structure theres not much point, plus you’ve got a bit more than media under volume2 (which youd have to mount in the container) that you may not want the container to have access to

I have checked, and I am already referring to the folder as you suggested.

  • /volume2/DownloadTemp for the manual import
  • /volume2/TV Shows/Battlestar Galactica (2003) (as the directory for the show in sonarr)

Should I raise this as a bug/issue on Github?

possibly. they all seem to be moves according to the debug logs (unless im reading them wrong)

19-11-9 21:04:52.4|Debug|DiskTransferService|Move [/volume2/DownloadTemp/1.TV/BSG Remux/S2/BATTLESTAR_GALACTICA__s02e20.1080p.Bluray(DISC_1).Title4.mkv.mkv] > [/volume2/TV Shows/Battlestar Galactica (2003)/Season 2/Battlestar Galactica (2003) - S02E20 - Lay Down Your Burdens (2) Bluray-1080p.mkv]
19-11-9 21:07:12.1|Debug|DiskTransferService|Move [/volume2/DownloadTemp/1.TV/BSG Remux/S2/BATTLESTAR_GALACTICA__s02e16.1080p.Bluray(DISC_1).Title4.mkv.mkv] > [/volume2/TV Shows/Battlestar Galactica (2003)/Season 2/Battlestar Galactica (2003) - S02E16 - Sacrifice Bluray-1080p.mkv]

any chance it was still seeding when they were being moved? maybe check that Settings > Media Management > Use Hardlinks instead of Copy, is ticked and try again, just to see if it makes any difference or not

This was importing TV Show that I ripped from bluray so no seeding on the file at the time.
I checked and the hard link option was already enabled.

Bug raised on Github

Same as I commented on the GHI:

Based on the logs I don’t see anything being copied, instead it looks like Sonarr it hardlinking the file to the backup file and moving it. This allows Sonarr to validate the file was moved without truncation without actually copying the file.

Trace logs will confirm that’s the case.