No announcement yet.

Recovery Files - Local or Central?

  • Filter
  • Time
  • Show
Clear All
new posts

    Recovery Files - Local or Central?

    We've just experienced our first real "O.M.F.G" moment with one of our workshared models - and although we've "fixed" it - I'd like to see if I can get a better handle on what might have happened.

    User A had a crash, with the option to save a recovery file.
    They saved the "recovery" suffixed model to the same folder location as the central model - Revit automatically created a central-file-backup folder.
    Closing Revit, User A deleted all her local files manually in windows, then re-opened the original central file to create a new local
    At this point however every effort to synchronise the new locals reported "file is being accessed"
    I whipped around the office, had everyone unload the model from their models, but that still didn't allow the sync
    I had IT check no processes were being run on the central file - there weren't.
    I then was informed someone else had a local file open, but couldn't sync that either.
    Since the central file retained it's original name I was confused
    Stuck in sync/save loops we had to force-close Revit on all the workstations running a local file.
    To resolve the issue, I opened the central model, (not as a new local, or detached) with an audit (that reported nothing?) and saved-as a new central file, with a new name. Which behaves perfectly.

    Any ideas what might have happened?

    It also happen to us last week. My problem is i cannot create new central file because some of my team did not yet done synchronizing there local to the central. because the error "file is being accessed" is always prompting. some of then have have done a lot of work in there local. that's why as much a possible i need to save the central.

    Now what i done is. ask our I.T. to close all the Revit AR/MEP/SE and Reset the Server. then after that i open first all the AR local then try to synchronize it to central and it work perfectly. which is i think, the problem is the connection to the server but i am not sure
    Last edited by engel_hg; November 18, 2011, 03:27 PM.
    Revit Arch 2013 Certified Professional
    Phlippines Revit User Group
    Architecture | Structure | MEP
    International Order Of DeMolay


      the first thing to realize is that the recovery file is just another flavor of local file for that user. No need to put a copy on the server unless you are making it a new Central, and then you follow the procedure in 4. In any case, my protocol looks something like this...

      1: Did the user have a successful SwC in the last half hour to hour? If yes, I usually have the user trash both the recovery file and the old local, and associated folders, then make a new local. The lost work doesn't take as long the second time I tell them.
      2: If the unsaved work is just to long a time or too important, have the user open the recovery file. After all other team members have done their own SwC, and a quick backup of the Central is made, the user with the Recovery file attempts to SwC. If it works, close and delete all local stuff and make a new local and proceed.
      3: Often the rest of the team can't SwC either because the crash happened at the moment the Recovered user was doing a SwC, and thus the Central is now "locked" by the OS. And Windows can sometimes take it's own sweet time releasing a lock, and sometimes no at all. IT should be able to verify who has a lock on the file, and if it is the user with the Recovery file, IT can force the lock off. That should allow the rest of the team to SwC, then make the backup and try SwC from the Recovery file. Likely this is what happened.
      4: If all of that fails, and the work in the Recovery file is simply the most important work on the team, the Recovery file is opened, then Saved as a new Central (which is totally different from just moving the recovery file to the server). Then everyone deletes all their local stuff and makes new locals. Note that everyone else looses their work, only the Recovery file work is salvaged.
      5: If the Recovery user's work is not singularly important, they just make a new local and lose their work. Basically option one again, but less by choice.

      In all cases I usually have the Revit Captain do an Audit on the Central file as soon as everyone (who can) has a good SwC. This is regular maintenance anyway, but if there are work loss problems happening it is worthwhile insurance. Assuming the project isn't huge and adding this to the list is going to take a while. In which case I usually push for Central File Maintenance that night and new locals for everyone in the morning. Unless it is the second such problem, in which case it is pencils down and Central File Maintenance time no matter what.

      Beyond that, things like Antivirus scanning of Revit files, DFS Replication of Central files or problematic Volume Shadow Copy configurations can all cause the issue, and IT may need to modify their approach to things if one of these is the problem. Also, I have seen this kind of behavior when one team member has 100MB network connectivity, and the rest have 1GB. Mostly this is not an issue anymore, as most offices are 100% gigabit ethernet now, but I have also seen situations where the switch will have/develop problems on one port, or a network driver will, sometimes even caused by a Windows update. You can usually see via the lights on the switch if a port is not connected at 1GB. And for what it is worth, it isn't always the person at 100MB that has the problem, but if someone is at 100MB they are probably the cause of the problem. In any case, if anyone working in Revit isn't at 1GB, that will eventually come back to bite you, even if it isn't the cause of the current issues. As will things like DFS-R or AV messing with RVT files.

      Last edited by Gordon Price; November 18, 2011, 10:25 PM.
      Pragmatic Praxis


      Related Topics