It is not uncommon to see this problem around the AutoCAD world. You press Ctrl+S or click the save icon and you get a message that says something like this:
“Unable to save to drawing K:\mypath\mydrawing.dwg
Drawing saved to SAV98C2.tmp”
In order to understand why this error happens, you need to understand how AutoCAD saves a drawing.
When you save a named drawing in AutoCAD, it actually does this (*steps 2 and 3 only occur if you have .BAK file creation enabled)
- Writes the contents of the editor to a .TMP file in the same location as the .DWG. (for example: sav8c.tmp)
- * Deletes the existing .BAK file
- * Renames the existing .DWG to .BAK
- Renames the .TMP file that is just created to .DWG
So if the .TMP file is getting created, AutoCAD is doing its job and saving the file but the O/S, for some reason, is not letting AutoCAD finish the save because it is blocking that last step, the .TMP->.DWG rename. The question is why?
- The most likely culprit is network issues. Try saving the drawing to a local drive. Does the issue go away?
- I have heard of cases where the network connection was unreliable and the O/S loses track of what session of AutoCAD has a particular drawing open. This could be the cause also.
- Certain network storage devices may be incompatible with AutoCAD. Check with your IS/IT people. Has anything changed recently?
- Try to delete, rename, or move the .BAK file that goes with the .DWG. If the .BAK is read-only or otherwise locked itself, then step 2 (above) will fail and stop this whole process. Leaving you with a .TMP file.
- Unlikely, but it’s possible that you have WRITE access but not DELETE access to the location from where you opened the drawing.
In the meantime, do not fear, your work is not lost. You can manually rename the .TMP file to .DWG and maybe start working locally until you can solve the problem.
Note: While looking in the directory where your drawing is located, you might see files with the file extension .DWL and .DWL2. These files have nothing to do with AutoCAD’s saving issue. A lot of people will say to delete these files to solve the problem and that is a fallacy. Those two files are only used by the WHOHAS command. File locking is handled 100% by the O/S.
See also:
