BACKGROUND: Cassandra was admired by the god Apollo and he offered her the gift to see the future in order to win her heart. Cassandra agreed to be his lover in return for his gift, but after receiving the gift, she went back on her word and refused him. Apollo was angered that she lied and deceived him, but since he couldn’t take back a gift already given, he cursed her that though she would see the future accurately, nobody would ever believe her prophecies.
BACKGROUND 2: Apple simultaneously depreciated their AFP protocol and made SMB the default network file share protocol of choice on macOS back in the 10.9 days circa 2013. Many Apple admins were horrified and warned of impending doom.
Now that we have the preamble over (who’d have thought greek mythology, macOS history and a bit of personal philosophy would be in one place?), anyone ever seen this message before from Microsoft Office?
Sadly I have, but for those that haven’t, you occasionally see this as a user if you are working on an Office document that is residing on a SMB network share. What I have NOT found is an explanation of exactly what’s going on. I will attempt it here.
When you create/open an Office file, the appropriate application creates a hidden temporary file that it saves any changes to. This leaves the original intact during modification. It also serves as a warning check to other users who would try to access that file that it’s in use.
To quote directly from Mike Hung [MSFT] on a Microsoft support forum:
When Word for Mac 2016 performs a save,
it saves to a temporary directory on the volume first,
and then swaps the file with the actual file the user
wants to save to.
We do this to prevent corrupting the original file.
Ok that’s the first piece of our puzzle as to what’s going on. The second piece can be found within the source code of Apple’s SMB stack. The author has provided some interesting comments in his code: (I’ve reformatted for the sake of WordPress)
(unrelated: but the comments in that file are VERY revealing!)
* smbfs_delete_openfile *
We have an open file that they want to delete.
Use the NFS silly rename trick, but try to do better than NFS.
The picking of the name came from the NFS code.
So we first open the file for deletion.
Now come up with a new name and rename the file.
Make the file hidden if we can.
Now lets mark it for deletion and close the file.
If the rename fails then the whole call should fail.
If the mark for deletion call fails just set a flag on the vnode and delete it when we close.
Richard’s Universal Truth in IT: The really nasty issues never have one direct cause, instead they have multiple indirect causes.
Microsoft’s attempts at file integrity are apparently clashing with Apple’s attempts at network file integrity. You can see this because when this error above occurs, the filename in the titlebar of the document changes to that exact “.smbdelete-xxxxx” filename in the error.
It’s looking a lot like Apple’s SMB cleanup code is attempting to perform operations on a file that Microsoft Office hasn’t quite finished dealing with yet.
Fixes? Ain’t no fixes! At least, nothing your average Apple administrator has the power to do. I’ve found that 3rd party SMB support on devices such as Synology NAS are more susceptible to this. Network latency can also be factor but frankly this HAS to be fixed by Apple and Microsoft (oh and Adobe too as their products are effected badly) working together.
There is a workaround.
Copy the file(s) locally, work on it/them there and copy it/them back when done. I do not like this, but it works.
So what’s the greek mythology got to do with any of this? Simple. I’ve been screaming about this kind of stuff with Microsoft and Adobe products for YEARS. This has been known about since the days of Office v.X ! I’ve been telling this to people at various organisations for years and I get looked at as though I was crazy. Hence the comparison 😉