Thanks for the extra info.
I've dug into how this works with Windows file servers, and the problem is Samba will not correctly report if something is a link/junction/etc. like a Windows file server does. This means we cannot tell that the folder is really something which points to another drive.
We use ask for the folder's attributes and check for
FILE_ATTRIBUTE_REPARSE_POINT to know if it's a link/junction.
From looking at the Samba source, it looks like it can return that attribute sometimes but I'm not sure exactly when. It may depend on how the underlying filesystem reports things. But, looking at your logs, the attribute is never returned when Opus asks your Samba/ZFS server about the source or destination directories.
(Checking my own logs, with a Windows server and a junction at the other end, I can see the attribute coming through fine, as well as several others that Samba isn't reporting. Samba in your logs only reports
FILE_ATTRIBUTE_DIRECTORY for each dir and nothing else.)
If that attribute is set, then we would request the link/junction's target path using
You can see here the only use of that IOCTL in the server-side Samba source that I can find:
/* Fail it with STATUS_NOT_A_REPARSE_POINT */
DEBUG(10, ("FSCTL_GET_REPARSE_POINT: called on %s. "
"Status: NOT_IMPLEMENTED\n", fsp_fnum_dbg(fsp)));
I also found this email from 2013 which says they weren't planning on implementing
FSCTL_GET_REPARSE_POINT (although that may be out of date, it looks like it's still true in the current source code).
Working around the lack of
FSCTL_GET_REPARSE_POINT would be possible, if we just assumed anything with
FILE_ATTRIBUTE_REPARSE_POINT on it was on a different drive (maybe as an advanced option, since it would slow down moves between links that are on the same drives), but with both pieces of information missing, we'd have to assume every folder was a different drive, and make all moves slow.
So it does not look like Samba supports the two Windows/SMB APIs which we use to test if two folders are on the same drive.
If this works in Explorer, it may be trying the move via rename and then falling back on a copy-then-delete after that fails. The problem with that, as least how our code is structured, is it would not report progress properly while the file was being removed, since we need to know in advance which method we'll be using.
We need to think on this and discuss it further within the team. We could refactor a lot of the copy code to deal with this, but given this is a very niche thing which I don't think has been brought up by anyone else ever, I'm not sure that makes sense, since it involves changes to such a complex and fundamental piece of code (the copy code is very complex, for all the situations it deals with, including things like archives and FTP, and breaking file copying can be catastrophic, of course).
From our point of view, it's a shortcoming of Samba, since it should be able to report the real paths to things, or at least report that they are links and not normal directories. I'm surprised using that kind of ZFS link via Samba doesn't cause problems with more Windows software than just Opus.