Wednesday, November 05, 2008

CSI Revit (Part II): Tracking down the culprit

We left with how to read journal files, and a suggestion on practicing reading them. Today, we're going to talk about where and how they can come in use for some computer forensic detective work.

Allow me to set the scene.
  • At Burt Hill we encourage and keep multiple local files when working on a workshare project. This has come in use multiple times, and for multiple reasons. We usually suggest that a user maintain a week's worth, and sequentially overwrite the files.
  • A project team has been working diligently to their deadline. Annotating views, drawing details, setting up sheets, running check prints.
  • They're busy working the weekend, 12 hour days to meet their Monday evening print deadline.
Sometime late Sunday or Monday morning, someone realizes all the Keynotes are missing from all the views. The team knew they had been there as they had previous copies (digital & physical) of views/sheets that were complete.

The first step, was to figure out what could be done in the short term to deal with the problem. This is where our rule about multiple local files came in handy the first time. Team members were able to immediately start rescuing views by opening old local files and copying/pasting the missing Keynote Tags from old to current.

The next step was to figure out what happened to the Keynote tags, needless to user error was the primary suspect, but, whose error, and when? How many times have we all worked on large Revit projects, and had something "go missing" or something was "deleted" and we are left to wonder, what, who, when, how... Well one of our top users decided to track down what happened.

To start, he looked through the local files, local file history, and central file history to narrow down when the keynotes disappeared. For those who don't know, for both central and local files you can pull the save history from the File menu (see screenshot).

Once he had an idea of where to look more specifically is where the journal files became useful. With some sense of the approximate time to look for, our investigator used the find command to look for keynotes. What he eventually found was this in a journal file...

One of the users on the project had used "Select All Instances" of the keynote family used in the project, and hit "delete". For some reason this user was under the impression that "Select All Instances" was valid only for the active view! As it was, the user was helping our investigator, and was the one to find the four pages of text showing every keynote being selected, it was quite the teaching moment for the whole team.

While it took the lead investigator a good chunk of his day to sort through all the related files. It was needless to say quite useful to determine what had happened, most importantly, to help assure it doesn't happen again. While the copies of files, and back-ups helped with restoring the missing work, and helped to narrow down the time period in which the mistake happened, without the user's journal file there would have been no way to so clearly identify the culprit.

Check back at the end of this week (or beginning of next), for the my wrap up on journal files.

No comments: