Hi, Generally, the.tmp file is the temporary files. Generally, a temporary file is a file that is created to temporarily store information in order to free memory for other purposes, or to act as a safety net to prevent data loss when a program performs certain functions.
I am not sure why your Word for Mac 2016 create the temporary file in a new folder. I suggest we can use a 'clean startup' to determine whether background programs are interfering with Office for Mac, then confirm if the issue persists.
Regards, Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]. Winnie Liang TechNet Community Support. I don't understand why this has been marked as an answer.
The Temp folder has moved and I am not sure that the OS does not change the Temp folder over time. Here is how I am able to find the files in the Temp folder: 1.
It's not even a work around. At best it is a troubleshooting measure. But the OP has never come back to report if he found the culprit. We too have the problem but very sporadic and we don't know how to repropduce the error. So this approach dosn't help us at all. I also wonder how other software could interfere? Preventing Office from deleting the folder?
Or causing Office to create the folder in the wrong place or with he wrong permissions? Clearly as employees of the company that created the program, you should be able to shed some more light on the issue and give some hints on what kind of 'background process' one has to think of.
' I am not sure why your Word for Mac 2016 create the temporary file in a new folder.' - The answer lies in the code! There must be the ifs and elses that test the conditions and decide to put the folder where we find them. This said, I of course appreciate your help very much. Where would we poor supporters be if we had not the backup of knowledgeable people like you. This seems to be how Word 2016 is now saving backups when you check 'always create backup copy' under Preferences and Save - by creating a folder with that same file name and placing it next to the backed-up file.
In my case, the extension for the backup files within the folders is.docx, not.wbk. The problem is, these folders causeconfusion and clutter. I have tried going into Preferences, File Locations and changing the location for AutoRecover files, but this has no effect - I guess that's a different feature. After a few weeks of use, there is nothing in my designated folder for AutoRecover files and word is still creating the backup folders. Microsoft needs to clarify how we can choose and set the location of our backup files. I'm also confused as to why Word tech wouldn't know about this feature and how it works. I've consulted someone by phone as well and they weren't familiar with it.
I've just had a client show up with the same exact issue, it's just leaving the folders there, after going through all sorts of forums and troubleshooting, I thought perhaps it was server side issue with the filesystem as to why it wouldn't delete the files, but it has reoccurred on a different share with a different user at the same client. This topic is definitely not yet answered. The question that probably needs to be answered: Is there a way to turn off this automatic folder creation for network share files, or a way to set a manual path for these backup/temp files to the local filesystem temp folders instead of the active folder the file is opened from?
Just to expand on my experiences: There's no setting for this as this is something that ONLY happens when your Mac is saving Office documents (Excel/Word) against a mapped network folder (SMB or AFP) where the files are residing on a DIFFERENT subnet. To prove this point: I installed the same Win2012R2 on my local on-premises network and in Azure as a virtual machine. I setup shared folders and then from a Mac client I connected (both SMB/AFP) to them, tried saving the Word/Excel file. On my local server (same subnet) these folders didn't appear and saving is almost instant. On Azure, the folders appear, and saving takes appr. 10-20 seconds.
Packet signing is turned off. And no, it's not a latency issue at all as other file types work really well (txt, photoshop, indesign, etc). When PC clients connect, there are no problems at all regardless of destination end-point. For us it was the setting: Word Preferences Save Allow Background Saves Our issue was worse as users could not save directly to the server at all.
I have a feeling it has to do with our Sync software (CA RHA). We had a similar problem with Windows Office saves as Office apps, ONLY WHEN USING SMBv2, create a.tmp file in the same directory when saving. This is in addition to the $xxxx file. Our sync software was causing long delays as it was interfering with these.tmp files as I don't want to 'sync/replicate' them I had them explicitly excluded. There is a CA KB article on the issue.
I also exclude.DSStore files because of the garbage they generate (it starts to add up after terabytes of data) and I have a feeling the same thing is going on here, in the 'temp folder' there is a.xxxx file attempting to be created, but unlike Windows version of Office, Mac versions time out is much faster and so the save is canceled almost immediately. I've been using CA RHA to replicate data for some time and previously we had SMBv2 intentionally disabled as we though this was the culprit, but after doing packet captures, it seems Office apps treat saving to remote source differently if connected via SMBv1 and SMBv2. I have no idea. With SMBv1 being such a security issue now, we had to figure out SMBv2 and discovered its not the protocol, but the apps using the protocol. Other programs do not seem to have this issue OR utilize a different 'temp' naming schema. So pending your setup, likely you do NOT have CA RHA on your servers, but you may have backup software, settings in MS FSRM file screens, etc that could potentially have the same effect. Disabling SMBv2 seems to resolve the issue, but is not a good work around.
I'm now trying to identify how much of a risk it is to OSX users in disabling 'Allow Background Saves' and is it better to force them to save locally, then drag to the server. I am also not sure why this is marked as answered and the reply by Winnie Liang is not anywhere close to an answer.
I am having this exact issue in our environment as well. Sometimes the temporary folders that are created (usually 2-4, sometimes up to 6) disappear roughly 1 second after they are created when saving. Other times, the folders stay and you have to manually delete them. The times when they disappear on their own, usually only 2 folders are created. I have unchecked 'Always create backup copy' in Word's preferences and 'Allow background saves' was already unchecked. These users are on OS X 10.13.3 and Word 16.10, however one Mac was on 10.11.6 and still had the issue before upgrading to High Sierra.
This is a big issue that I feel is being ignored. I called Microsoft and got bounced around eventually to a paid service. I am at a large university and working off a network share connected via SMB is extremely common here. This needs to be addressed and fixed.