Recently started getting the following error "An error occurred moving Incorrect function. (1)"
It only happens with when moving files to and from SMB 3.0 shares. Windows file move (command line or cut and paste in explorer) work fine. Machine with DOpus and file shares are in the same windows domain.
The only event in the client log does not seem to be related, but here it is:
The start type of the Background Intelligent Transfer Service service was changed from auto start to demand start.
Nothing useful in server logs, but verbose event logging is not enabled.
Client: 12.6 x64 under Windows 10 Enterprise 1709
Server: Win server 2016 DFS and Synology DSM 6.1 (All on the same domain)
QUESTION
How is Directory Opus file move different from Windows file move?
Please point me in the right direction so I know where to look.
Make sure the Synology's firmware and any related client or server side software is all on the latest versions.
Problems with their NAS devices are usually fixed by updates, in our experience over the years.
A search on "incorrect function synology" shows DSM 6.0 appears to have introduced a problem that started affecting Windows Backup (and maybe other things), but I don't know if it is the same thing you are seeing.
Synology storages were the first place where we looked. All are running latest DSM. Nothing fancy like NFS or snapshot replication. Plain vanilla DFS with MSDFS VSS.
The error that we are seeing does not have a corresponding message in Synology logs. Looks like DOpus fails before writing a single byte to Synology.
Can DFS be a culprit here? Can DOpus treat DFS differently than the underlying OS? DOpus does not even show DFS folders as symlinks, but I don't know if it is supposed to...
Opus has no knowledge of DFS; everything Opus does is at a much higher level. It basically calls CreateFile and then WriteFile in a loop, then some other APIs to set file attributes, ADS metadata, and so on.
If Opus is configured to use non-buffered I/O then that can cause some problems with certain devices that aren't tested with that, but in the example above that would only normally apply to the read side (the local drive), since non-buffered I/O is not used for network drives, even when turned on. (Preferences / Miscellaneous / Advanced: copy_nonbufferio_threshold)
Buffer sizes can also play a part with some devices (for some reason), but usually only affect speed, not whether or not things work. (Preferences / Miscellaneous / Advanced: copy_buffer_size)
The types of metadata and file permissions Opus is configured to copy (Preferences / File Operations / Copy Attributes) can play a part, and be a difference between Opus and Explorer. But if they were causing the problem I would usually expect the error to show up at the very start or end of a file, not ~7MB into a file as in the screenshot.
If the failures are always on certain types of files (e.g. archives as in the screenshot), I might suspect antivirus, indexing or something similar which is scanning or blocking the files and interfering with the copy. (Most likely on the destination side of things.)
Using Process Monitor to see exactly which operation on the drive is failing may shine some light on things. If you save a log in PML format and zip it up, you can send it to us via private message or email it to crashdumps@gpsoft.com.au and we'll try to see if we can work out which part is failing.
I will setup a clean environment and run system and network profilers during DOpus move and Win10 move. If it turns out to be a DOpus issue will send you all the logs and steps to reproduce.
It will be a lot of fun to do. Time to learn how DFS actually works. Never understood how the interaction of Client -> "DFS namespace server" -> "leaf storage node" looks from inside.
Update:
Problem disappeared around the time when Synology updated DSM to build 23511.
Not sure what exactly changed, but I was able to go back to using Directory Opus for file operations.
