.dwg reverts to old version

[kevwalker]

After completing extensive changes to a drawing and saving those changes back to the file the drawing will revert to an older version of the file. This has happened to multiple files recently. It's possible that this is not an AutoCAD issue, and that all of these drawings were overwritten with old changes at the same time sometime last week (as we are able to trace the old versions back to around 3 days prior). But I'd like to rule out AutoCAD as the culprit if possible.

I've ruled out our iDrive.com online backup as the problem through troubleshooting with their team (iDrive does not assume lock priveleges on any files, though it does back up open files). As a precaution, I've turned off their "continuous backup" option in the event that the problem is related to multiple open instances and read-write priveleges, knowing that AutoCAD's drawing lock procedures are fairly unique.

Could this issue be related to a faulty server Shadow Copy procedure? There are event logs that point to server shadow copy errors around the time that we have lost data.

As always, I stay wary of user error when many client computers are attempting to access files within the same project, but this does not seem to be the case. These re-writes seem to have happened over the weekend, even after the up-to-date versions of the changes have been successfully saved to the files (and no errors were present upon saving any of these files).

We've received no prompts from AutoCAD that any of the affected drawings required recovery.

I've read up on the file locking procedure of AutoCAD (See user: jason martin's 08-01-2002 response to jeffva's post titled "Unable to save drawing?"), but am not sure this is a problem of read-write access.

We are working on multiple files that have had this issue recently.

We are all using Autodesk Architectural Desktop 2005 SP1 with all hotfixes installed.

All of us are on XP machines accessing files on a server.

I know this is a vague post, but I welcome any suggestions of things to investigate.

We'd like to rule out as much as possible so that this doesn't happen again, as it is a huge time-suck and a waste of company time and resources.

Thanks in advance.

[pendean]

Save to your desktop, on your PC.

close AutoCAD.

Open the desktop file, still the 'new'? If yes, copy it to a thumbdrive and to the location you normally save files.

You now have three copies of the one file.

Next time you open the file (you provide no timeline in your post), which of your three copies changed all by itself? That's your culprit, the one app with access to the location that changed.

[kevwalker]

David,

Thanks for the reply.

Using similar steps you describe, I have yet to replicate this reversion to old data.

I have determined that the reversion seemed to replicate information in the .bak file (in the same directory as the file iteself) for each .dwg infected. Our autosave (set to every 10 minutes) DOES catch the majority of the lost data in this instance, providing we can determine who had the most recent access to the file, and thus the most recent changes.

It is my belief that some sort of copy procedure (restore of a backup through third party software, perhaps?), is the prime suspect.

Not ruled out is a failure of AutoCAD to lock read-only drawings after the original drawing was saved and closed, allowing the read-only version to be saved over top of the newer work, but this is mainly conjecture on my part.

Again, without being able to replicate the situation, it is hard to say what occurred, but I appreciate your help in trying to narrow the scope of my investigation.

Here is a timeline as best I can conjure it:

Thursday-Friday: intensive work done to a project consisting of 42 Sheet files, 5 view drawings, and 6 constructs.

Saturday-Sunday: work continues (deadline push).

Monday: 5 sheet files and 1 view drawing have reverted to a version around the time of Thursday.

Autosave catches the majority, but not all of the changes, and we have to re-check all the drawings to ensure we catch all the discrepancies (lost a day).

Renaming the .bak file in the same folder as each of the affected files shows a version of the file which is similar, if not identical to the reverted file.

It's perplexing in a number of ways. If it was a failure of a backup, why would it affect some, but not all, files in multiple folders?

If it was an AutoCAD glitch, what would cause it, and why would it affect these (seemingly random files)?

So far things have been fine moving forward, but we are very cautious (making a "safety set" of the files after we determine that they are correct and current).

I'm having the server checked for any issues, including latency issues that could affect read-write procedures involving multiple users accessing the same files, and will post if we find anything else useful to report.

[schlicher70]

We have been experiencing files reverting to older versions. This morning worked on a file saved left for lunch when I returned and reopened the file it was reverted to the original from earlier that day. I went to another users workstation that was xrefing my file and his showed all the changes and had not reloaded since I closed. The drawing recovery did not list any versions.

How to restore the changes:

Browse with windows explorer to the file location right click and choose restore previous versions. you then see a list of versions including my 11:59am save before lunch. Then choose copy to ensure you have the right file. copy to desktop or another location. open the file all my changes were there. I am not sure if this is a server issue or a civil 3d issue. I was able to get all my changes and found this is much better than the drawingrecovery command for restoring saved versions. 

[pendean]

You are describing a Server OS feature that may be the culprit: talk with IT, try to replicate 'deliberately' while the folder is being actively monitored to see what the sequence of the file disappearing is. Remember, AutoCAD writes a temp file, deletes the old dwg, then renames the temp file. This process cannot be broken or interrupted.