Topic: Qsave Error

[Krushert]

I have a qsave error (see first screen shot) that for one file that can be reproduced on any machine.  IT comes up with the following error message and then if you were to do an open file, go to folder where the file is, the file has been deleted (see second screen shot).  if close the file open dialog and then preform a qsave you do get the error and now you can see the file if you were to do a file open.   Autocad or the file does not crash. 

Any ideas? 

This is what I have done up to now.

• I have saveas the file out to a different name and can not reproduce the error within that new file.
• I have wblock the geometry out to a different file name and can not reproduce the error within that new file.
• I have copied and paste the geometry out to a different file name and can not reproduce the error within that new file.
• Take any of the above file and rename them back or savas back to the orginal file name; the error is back. 
• I have made sure everybody is out of any read-only version and any file that references that file and then went through the folder and deleted any and every temp file and any version thereof, and then repeated the process above and the error comes back. 
• Google Search for about an 1/2 with nothing even close

  :realmad:


I am in the process of leaving the file renamed and then changing any file that references that file to the new name.  But this also affects my consultants and of course the project going out the door next week. 

[Rob...]

I've gotten the same error many times. IT has attributed it to the slow network connection this part of the office has. It's very scary to find out that the .dwg files that you've been working on for over 5 years are missing. I can do a second QSAVE successfully every time this error comes up.

[MP]

Huge reach, but check the value of the isavepercent variable. Set it to 0 and see if that remedies the problem.

[mjfarrell]

have you altered the folder properties?


I found this elsewhere:


When I change the properties of the autosave folder to remove the delete rights, autocad comes up with the error "unable to save to drawing....drawing saved to..."

[mjfarrell]

Also  right click the BAK file and check the security settings for the file it may not be inheriting security from the folder. Set the .bak file to inherit security

[mjfarrell]

Further verify that there are NO files of the type  existence of a DWL and DWL2 in that folder.
These files are of the 'hidden' type so you will need to enable viewing them.

[BlackBox]

Just recently we had a user who experienced a fatal error, and subsequent shutdown... at which time the *.dwl* files were not fully handled, and remained in that directory. They had issues modifying the file, until they manually deleted them (with the drawing NOT open).

... But I thought that would cause a Read-Only error upon drawing open??? *thinking back*

[Biscuits]

We have had similar issues. Read-only messages sometime appeared as well. Turned out that Network location was at it limits for storage. Maybe something to consider.

[mjfarrell]

two votes for DWL files needing to be deleted....


do I hear a third?

[Rob...]

Yup, I just wish I could think of a way verify it.

[Krushert]

Huge reach, but check the value of the isavepercent variable. Set it to 0 and see if that remedies the problem.

I was responding to this when Time Warner decided to haven an outage yesterday. 

I did that at first and thought that was the problem.  But ensuing test latter (see OP) determine that had no affect.  FYI:  Isavebak is set to 1 upon opening the drawing.

[Krushert]

have you altered the folder properties?

Would this not affect all drawings?  But no, the folder properties were not altered.


I found this elsewhere:

When I change the properties of the autosave folder to remove the delete rights, autocad comes up with the error "unable to save to drawing....drawing saved to..."

Would this not affect all drawings?  But no, the folder properties were not altered.  Furthermore the autosave folder, autocad temp folders are local to each user in each machine.  I reproduced this error in another machine.

[mjfarrell]

and what of the DWL files did you discover?

[Krushert]

Further verify that there are NO files of the type  existence of a DWL and DWL2 in that folder.
These files are of the 'hidden' type so you will need to enable viewing them.

In my O.P. I should have said that I checked for and deleted all temporary files, which included *.bak, *.dwl(s) and *.tmp files in the root folder.  I then went to my autocad temp and save folders folders deleted everything in those. 

Yes I have rights to view and touch.  One of the few times in the day that I am all powerful. 

[Krushert]

and what of the DWL files did you discover?

Sorry.  There were NO DWL files for the particular file in question.   I also made sure that no user had the file open in a read-only status or had a host file that the particular file was xref into.

[BlackBox]

Admittedly, I've not re-read the entire thread, so please forgive any duplication here....

Does this only happen on your computer - what about attempting this from another workstation?

Also, what version are you using?

HTH

[mjfarrell]

and what of the DWL files did you discover?

Sorry.  There were NO DWL files for the particular file in question.   I also made sure that no user had the file open in a read-only status or had a host file that the particular file was xref into.

Keep in mind that those files are HIDDEN, and most people do not display HIDDEN files by default in their folder views.

[rkmcswain]

I have a qsave error (see first screen shot)

The simple answer is (and I think someone mentioned it...) that AutoCAD cannot delete a file that it needs to.

When you save a named drawing, AutoCAD:
1. Writes the content of the editor to a .TMP file.
2. Deletes the current .BAK file.
3. Renames the current .DWG file to .BAK
4. Renames the .TMP to .DWG.

If step 2 fails because you do not have delete rights, then the process stops and you end up with a TMP file (as your dialog indicates). You can replicate this behavior easily by saving a DWG in a directory in which you do not have delete rights.

As far as the DWL* files, these are created and managed by the WHOHAS.ARX file and have *nothing* to do with AutoCAD saving (or not being able to save) a drawing.

[mjfarrell]

I have a qsave error (see first screen shot)

The simple answer is (and I think someone mentioned it...) that AutoCAD cannot delete a file that it needs to.

that would be me

As far as the DWL* files, these are created and managed by the WHOHAS.ARX file and have *nothing* to do with AutoCAD saving (or not being able to save) a drawing.

GOOGLE some more, as it shows up as a potential solution in more than one location. I didn't make any of this up.   

[rkmcswain]

GOOGLE some more, as it shows up as a potential solution in more than one location. I didn't make any of this up.   

AutoCAD does not know or care about those files (with the specific exception of the WHOHAS routine). They are simple text files. We have been down this same road before and I'm just relaying our lessons learned.

It is pretty easy to prove also.
1. Open a drawing.
2. Go to that directory in Explorer.
3. Find the DWL* files, change the security settings of these two files so that you do not have delete rights
4. Close the drawing.
5. The DWL* files will not be deleted
6. Now open a new empty drawing
7. Do a SaveAs, overwriting the original drawing.
8. The presence of the DWL* files will not prevent this Save from occurring.

[MP]

FYI:  Isavebak is set to 1 upon opening the drawing.

?? But 1 is not 0. Subtitle: Even if a isavepercent setting of 0 doesn't remedy your immediate problem it's the setting you should use. Hope you nail the cause of the problem.

[Krushert]

Admittedly, I've not re-read the entire thread, so please forgive any duplication here....

Does this only happen on your computer - what about attempting this from another workstation?

Also, what version are you using?

HTH

Yes attempted and recreated the very same error on a different machine. 

See Sig below.   

[Krushert]

and what of the DWL files did you discover?

Sorry.  There were NO DWL files for the particular file in question.   I also made sure that no user had the file open in a read-only status or had a host file that the particular file was xref into.

Keep in mind that those files are HIDDEN, and most people do not display HIDDEN files by default in their folder views.

Sorry should have been less of a wise crack with my response. 

Yes I have rights to view and touch.  One of the few times in the day that I am all powerful. 

[mjfarrell]

RK

Respectfully I have no need to run that experiment, as my understanding is that WHOHAS.ARX must be intentionally loaded, and many do not bother with doing so.
Further I do not, nor have not had the issue.  And as stated it does show up as a potential solution to this type of problem, and no potential solution should be omitted in a case such as this.

[Krushert]

I have a qsave error (see first screen shot)

The simple answer is (and I think someone mentioned it...) that AutoCAD cannot delete a file that it needs to.

When you save a named drawing, AutoCAD:
1. Writes the content of the editor to a .TMP file.
2. Deletes the current .BAK file.
3. Renames the current .DWG file to .BAK
4. Renames the .TMP to .DWG.

If step 2 fails because you do not have delete rights, then the process stops and you end up with a TMP file (as your dialog indicates). You can replicate this behavior easily by saving a DWG in a directory in which you do not have delete rights.

As far as the DWL* files, these are created and managed by the WHOHAS.ARX file and have *nothing* to do with AutoCAD saving (or not being able to save) a drawing.

The folder is wide open on permissions.  It is a project folder with 57 drawing files alone not counting all the other associated files for a project.  And further more I had the 4 base files open at the same time and made successful edits and saves to them.  3 other users where accessing other files at the same time. 

Now my question is could a just a file itself have it rights change?    Even after I have copied and pasted the line work into a brand new file?. 

[rkmcswain]

....as my understanding is that WHOHAS.ARX must be intentionally loaded, and many do not bother with doing so.

WHOHAS.ARX was rolled into the core of AutoCAD starting with the ±2008 version, so if anyone is running a version even close to recent, it's running.

Further I do not, nor have not had the issue.  And as stated it does show up as a potential solution to this type of problem, and no potential solution should be omitted in a case such as this.

I have to think maybe the 'solutions' you have run across were in error or pertaining to older versions of AutoCAD when they did use their own lock files. See also:  http://usa.autodesk.com/getdoc/id=TS19142

[Krushert]

FYI:  Isavebak is set to 1 upon opening the drawing.

?? But 1 is not 0. Subtitle: Even if a isavepercent setting of 0 doesn't remedy your immediate problem it's the setting you should use. Hope you nail the cause of the problem.

Sorry should have said that that the Isavebak is check and set to 1 upon opening the drawing though the startup function.  However during my testing, having it set to 1 or 0 the error was still present.

[Krushert]

I have to think maybe the 'solutions' you have run across were in error or pertaining to older versions of AutoCAD when they did use their own lock files. See also:  http://support.autodesk.com/getDoc.asp?id=TS19142

So why is 2012 still creating DWL* files?.  Interesting nugget of info; thanks.

[BlackBox]

I have to think maybe the 'solutions' you have run across were in error or pertaining to older versions of AutoCAD when they did use their own lock files. See also:  http://support.autodesk.com/getDoc.asp?id=TS19142

So why is 2012 still creating DWL* files?.  Interesting nugget of info; thanks.

1+ ? ... Yes, thanks, RK.

[Krushert]

A useless peice of information that is a day late and dollar short.

My ITwit came to me just and said "What was that name of the file again?  Yesterday morning at 8:31 am the server backup software cough up an alert that this particular file's bak file could not be back up and was skipped.  The ITwit stated that usually happens when a file is corrupt.  (BAK files are backup too as part of the process)  But the issues was still happening even after I deleted the bak file.  And this morning there were no issues with the backup software but there is no bak file also.



What I want to do, is to take the temp file (that I renamed and now using in place of the original ) and do a saveas to new file with original name.  Maybe there were ghost remnants and the server cleaned them up. A great big shoulder shrug over here.

[mjfarrell]

Sorry should have been less of a wise crack with my response. 

not a problem I didn't even see your (wise) crack   

[mjfarrell]

so is the issue remaining or resolved?

[Krushert]

so is the issue remaining or resolved?

Don't know, been running around here like a chicken with it's head cut off.  BRB

[Krushert]

What I want to do, is to take the temp file (that I renamed and now using in place of the original ) and do a saveas to new file with original name.  Maybe there were ghost remnants and the server cleaned them up. A great big shoulder shrug over here.

Okay so I did the above and so far with limited testing, there error seems to be gone.   I will test it some more then put the file back into production.

[rkmcswain]

So why is 2012 still creating DWL* files?.  Interesting nugget of info; thanks.

See last paragraph in earlier post.

 

[rkmcswain]

... the server backup software cough up an alert that this particular file's bak file could not be back up and was skipped.

Fits my theory. The BAK could not be deleted (as per the steps here) and therefore the TMP was left in place.

The ITwit stated that usually happens when a file is corrupt.

Not sure about corrupt, but we have files that get screwy file permissions every now and then and the same thing happens.

But the issues was still happening even after I deleted the bak file.

Can't explain that though.... 

[Jeff H]

If you can not post publicly or can post or PM and will set up the same path structure on external harddrive too see if works and look at the drawing with a database explorer to check all variables to see if something could be screwing it up?!??

[mjfarrell]

there's a hole in his theory   

[Jeff H]

I thought he could get to file just could not save?

[mjfarrell]

I thought he could get to file just could not save?

As I understand it....

whilst no one was aware; and later reported by IT to the user, something weird happened during a backup of the server, the file in question had a(n) error within the BAK file so it was not copied during the backup...thus the "can not save to same file name, saving to tmp file" error appeared.

renaming the file removed the error
saving to same name even WITH the BAK file deleted reproduced the error
tmp file has now been saved back to original file name in original location
the error is now gone

I imagine that any forensic evidence  of what happened to the file or directory has also been destroyed by now as well

[Krushert]

So why is 2012 still creating DWL* files?.  Interesting nugget of info; thanks.

See last paragraph in earlier post.

 

Ahh.  I did not look very hard at the name of the arx file.  Got it.  moving on.   

[Krushert]

Thanks for all the help and lessons.  Learned a lot on this one. 
Thanks Guys.

[Daniel J. Ellis]

there's a hole in his theory   

Dear Liza, dear Liza

dJE