No announcement yet.

"Lost" folder locations bringing Revit to it's knees...

  • Filter
  • Time
  • Show
Clear All
new posts

    "Lost" folder locations bringing Revit to it's knees...

    Further to our server woes (see other thread) last week we were experiencing some painfully erratic behaviour with our NAS - with intermittent (sometimes non-existent) access making it impossible to get to our libraries.

    We ARE (not were) migrating the data on (one) NAS to (two) SAN arrays, but that's a "size&speed" upgrade - although (despite my protests) we're doing the stupid thing of moving it all - rather than sorting it all out then moving it... so we'll be replicating all the years of accumalted disorder and clutter.... but that's not the problem.

    The problem is, with Revit (and a lot of other applications) setup to "look" at folder locations - when the locations become inaccesbible, we've found Revit is brought to a grinding halt - to the point where even working locally still is practically impossible.

    Now I know if something is not there, it's always difficult for a computer to know that until you ask to look for it... the lag (say through Windows) is never much more than a few seconds before you get the "Connection can not be established" or some similar warning dialog. Revit doesn't tell us this though - and seems to get caught in a never-ending loop.

    But clearly, it's very convenient to have library locations defined (in a program like Revit). The re-pathing to new volumes when data gets moved (as we are doing) is a necessary evil - and takes less than a minute per computer. But how can we keep Revit from "looking" to somewhere that isn't there (when things do go bad?).

    Is there a "safe mode" ? Are there ways to "fake" the path so that Revit always see's something - even if it's not the right thing?
    Last edited by snowyweston; October 4, 2011, 07:33 PM.

    Revit is "looking" for the exact unc path name that the file was created under. If you change that path, Revit will not "find" the new path.

    The only way we have found when replacing hardware where Revit files are located is to actually name the new hardware with the exact same name as the "dead" hardware, turn the entire system off, reboot and it works. Good luck!
    Cliff B. Collins
    Registered Architect
    The Lamar Johnson Collaborative Architects, St. Louis, MO
    Autodesk Expert Elite


      This is a pretty good argument for using DFS & Network places. DFS defines a virtual location on the server, and the Network Location provides a way for Autodesk products to "see" the DFS resource. When you move things around in the server room, DFS makes it transparent to Revit. Note that you have to use Network Locations to do this, as Autodesk uses their own in-house File dialog that STILL, after all these years, doesn't handle direct access to the DFS share. But Network places are a more graceful approach anyway, and will show up in the Look in" drop down in Autodesk products, as well as the side bar in any app that uses the MS File dialog.
      All that said, there is no easy way to address this "after the fact". Any file that was started with this DFS/NL will just keep on working after any server room changes, but anything that predates this implementation will need to be manually "fixed" after DFS/NL is in place. And I don't know of any good scripting/API tools to automate the fix, but man that would be nice.

      Pragmatic Praxis


      Related Topics