The ### means a random HEX value set by AutoCAD, like 12 or 123B or 12A.
This posting refers to failures in saving AutoCAD files and the increasing
presence of temporary files like, ATMP#### (i.e. ATMP1234) and SAV###.tmp
(i.e. SAV13A.tmp), that should not be left after a successful save. In some
cases, the CAD user ends up with a complete DWG file, including changes. In
other cases, the DWG is completely missing. I logged a support call with
AutoCAD, Case No. 1034177, and found that the errors my company are
experiencing have plagued AutoCAD for many versions, without a successful
resolution. After I heard this, I ran a dir /s /u ATMP* on 4 or 5 of our
servers and found that we have close to 1,000 ATMP#### files, by an
assortment of users. For some reason, some of our AutoCAD 2004 (ADT) users
still generate ATMP#### files, even though our trace does not show that this
file name is used. Possibly the dwg was originally a 2002 format and later
saved to 2004 format? We are trying to figure this one out.
I also scanned our networks for SAV###.tmp files since December 31, 2003,
approximately when we began to use AutoCAD 2004. This file should be renamed
to Filename.dwg if the save is completely successful. The number of
SAV##.tmp files is also large. One reason we have so many and have not lost
many dwg files may be that the users get an error message if they fail on a
regular save or a Qsave. When they see the message, they can save again
until they are successful.
We have noticed that if you do a File - Exit or close the file, and tell it
to save, it may fail and produce a message, but it goes ahead and closes,
making it impossible to try the save again. In these cases, the dwg file is
lost and we have to help them find their Sav###.tmp file so that it can be
renamed to the missing dwg. This is a bad situation, especially if they do
not observe the message.
My staff installed a diagnostic program, Filemon, and used it to track what
AutoCAD 2004 does when a file is saved. We captured file activity from the
Save and came up with the following process. In this process, all of the
files were created in folders on the drive letter that the file was opened
on. So, for example, if the file was opened on D:\Temp, all of the files
mentioned in the process steps would be in D:\Temp. The following list is
based on the file Test.dwg residing in the D:\Test1 folder.
1. The user runs File-Save or Qsave
2. Some undetermined information is read from the Test.dwg file that is
being saved (even though it is open at this point!).
3. A file called D:\Test.dwl is updated. This file shows who currently has
the file open for read)
4. A file, D:\Test1\Sav###.tmp is created and the work that has been
accomplished is written to this file. Eventually, this will be the new
5. A file called D:\test1\Tes###.tmp is created. It then deletes the file.
6. The original file D:\Test1\Test.dwg is renamed to D:\Test1\Tes###.tmp. We
think the Tes is the first three letters of the dwg file. This will become
the bak file.
7. The file D:\Test1\Test.bak is deleted.
8. The file D:\Test1\Tes###.tmp is renamed to D:\Test1\Test.bak.
9. The file D:\Test1\Sav###.tmp is renamed to D:\Test1\Test.dwg.
10. AutoCAD looks for a D:\Test1\Test.dwk, probably to support old versions
since the dwk file locking is not used in 2002/2004. Maybe they are checking
to see that no one opened the file while it was being saved?
11. The file D:\Test1\Test.dwg is opened.
One interesting thing is that I could find virtually no CCC##.Tmp files on
our network. This means that these files are almost always renamed to .dwg.
This contrasts with AutoCAD 2002 which seems to leave many Atmp#### files
stranded. In 2002, the Atmp### is renamed to the dwg file.
Another possible observation is that the variable ISAVEPERCENT may have an
effect. It seemed that setting it to 0 caused more failures. However, later
when it was set to 50%, we had a failure.
One of our techs was losing his dwg files. But, the Sav###.ac$ file existed.
So his process was crashing about Step 8. This happened if he saved his
drawing on a network drive or on his local D: drive. I have two other users
that have lost dwg files in a similar fashion. I have hundreds of others
that left Atmp#### files, but did not lose their dwg file. I am not sure why
this is. Sometimes, a message is generated:
When I discussed this with Autodesk, they have been aware of this problem
for some time. They have had Microsoft examine their code. They claim that
Microsoft declared their code sound. My evidence shows that this is not
true. So Autodesk has blamed slow computers, too fast computers, servers,
using CAD files over a WAN-speed connection, Windows (losing lock requests)
and such. All of these put the blame on the local hardware, software or
network. Since a lot of file re-naming is involved, Windows must lose some
of them due to timing issues. Probably Microsoft needs to fix something or
explain the solution to Autodesk. I suggested that Autodesk change their
code to detect the failure and then give the user a chance to try again. The
tech support person told me they were worried about tinkering with the
code - that they could make things worse.
I am concerned that we are getting hundreds of the Sav###.tmp and Atmp###
files per month. This started in late April 2004. Prior to this, we have
some, but not nearly so many. In April, May and June, we converted our
servers to Windows Server 2003. We also changed our domain name and
instigated Shadow Copy. We speculate that Shadow Copy may aggravate this
problem, but it is only a theory.
My next step is to log a call with Microsoft support. If anyone has
additional information, please post it. I will do the same.
I don't know if you are still tryuing to resolve this issue. It has recently become important to us, because we have implemented a block level replication system for our backups, and it is being overwhelmed as a result (we believe) of the way AutoCad is saving files.
I have duplicated your filemon experiments, and confirmed your observations. I have also tried the same exact thign with Word, Notepad and Photoshop, and found that none of them have anythign remotely like the same save process.
Beyond that, I am simply nagging AutoDesk to cough up more information.
I'm having the same problem that you described. We have a File Server (Windows 2003) and the clients are using AutoCAD 2005 and 2006. They are having problems with some AutoCAD files to open and save them, taking some time. I checked the open files in the Server and found that when save a dwg file then a SAV###.tmp is created and then disappear but it takes some time longer than others.
Hopefully they are not losing the files but takes some to open or save some of the DWG files.
I though that it could be the antivirus in the Server (Symantec Antivirus) and excluded the folders and extensions related to the AutoCAD files but still the problem is happening.
Please if you have any idea or suggestion we can do I would appreciate it.
Let me know if need more details or information.
we have the same problems with inventor 10 sp3 and AutoCAD 2005. but our antivirus was symantec (worked for many years) but now we have trendmicro. 2 of 3(trendmicro) clients have this problem, the other 15 (symantec) clients doesn't have it. the autodesk support thought, that it's a trendmicor problem, but why do only 2 of 3 have this problem?
Our group met this same *.tmp with the same symptoms and i feel so lucky to find out this page and so so upset with no suggestions in. Now ,it happened with AutoCaD 2007 . Only one computer in our workgroup create these files in project shared folder. When he work with a .dwg file, it will be renamed to a sav###.tmp file. if someone open something refers to that old .dwg file, program will report xref missing . This problem took us so much time.
We are having the same problem. All the clients use AutoCAD 2007 on Windows XP Pro machines and the server is Windows Server 2003. I contacted Autodesk for support and here is the response I received:
There have been a few reported cases of this behavior previously. As of yet, there is no one specific reason for getting that error (aside from the confirmed Novell server setting, which obviously doesn't apply in your case with the Windows 2003 server).
In one case, the behavior was narrowed down to a certain set of drawing files which were all created on the same computer. See if you can possibly find any pattern as to who receives the error and with which files they're working with.
In other cases, reducing the Incremental Save Percentage setting from the default of 50 down to 0 (zero) led to a reduction in the message occurring. This value is stored in the ISAVEPERCENT system variable, so you can just type that at the Command line and enter 0 when prompted.
Also, to ensure data integrity, be sure that autosave is enabled. This setting is on by default and can be found on the 'Open and Save' tab of Tools > Options.
Another thing that you might consider is to see what happens if you pick a user or two and have them save their drawings locally first, and then move them to the server as a separate step. This would only be for troubleshooting purposes, but may help narrow the scope of the issue.
I tried everything they suggested, with no success.
I am also having this problem. I have isolated it to one machine that produces a "sav###.tmp" file every time a save is done and sometimes an error message indicating a problem while saving and that a tmp file has been created. This problem only started after a hard disc failure which required a complete reinstall. This machine no longer produces thumb nails for the files. I tried uninstalling and reinstalling AutoCAD but this did nothing. At this point I am seriously considering a complete format and reinstall to try to fix this.
I am using ADT 2006 and have been for a while. This did not occur until I recently purchased a new machine and transferred ADT to it. It didn't happen right away. In fact, it only started happening during the last couple of weeks. Nothing has changed on my computer, no new software except updates from Microsoft and antivirus software. I thought maybe there is a conflict with the antivirus software and ADT. When I turn off antivirus, I don't get the sav*.tmp files. When I turn it back on, the files return. so there is a link. There must be a conflict with the way ADT saves files and the way the antivirus software reads them. I have talked with the antivirus people and they don't feel it's their software. Since Autodesk has had this problem before, it must reside with them. Until they can come up with a fix, I'll be deleting sav*.tmp files.