2 Replies Latest reply on Dec 29, 2009 11:33 AM by ralvy

    Recovered Library and Blob



      Recovered Library and Blob


      Just ran Recover on a file as part of my routine testing. When FMDiff compared the Recovered file with the Original file, it found a Recovered Library and Recovered Blob. This seems related to my having deleted a graphic from the Original file. Recover, when creating the new Recovered file, created a new Base Table called Recoverd Library, with a field there called Recovered Blob, along with a new Table Occurrence called Recovered Library. After I created a layout for that new TO, I see a graphic I deleted from the Original File.


      Should I be concerned about the state of the Original file? Recover reported no errors. I only noticed the above stuff because I routinely use FMDiff to compare an Original file with a Compacted Copy, and  compare an Original file with a Recovered File, to test for possible hidden corruption, as suggested by FMDiff developers.


      It sounds like it's a matter of FM not recovering unused space after I delete the graphic. I deleted other graphics from that file also, but only this one seems to have resulted in deleted space not being recovered. 

        • 1. Re: Recovered Library and Blob
             You might try the save a copy as.. option and use the "compacted copy" option to make a copy of your unrecovered file. Then, recover that file to see if you get the same results.
          • 2. Re: Recovered Library and Blob

            Thanks for the reply. Running Recover on a Compacted Copy gives the same results. The FMDiff web site talks about Recovered Libraries and Blobs as arising from times when FM fails to remove a deleted object from the database when the pointer is deleted. So the object still occupies space, but isn't seen by the solution. According to FMDiff's developer, there's no way to remove that stray object without running Recover, and then removing the Recovered Library table from the Recovered file. The stray object is a graphic I deleted from a layout.


            You wouldn't even know about the stray object unless you loaded the Recovered file with FM (or ran FMDiff), because Recover reports no problems that relate to orphaned objects. If you load the Recovered file, you'll see the Recovered Library table.


            Seems to me that Compacting should be able to delete orphaned objects like this, but perhaps Compacting relies 100% on pointers. If that's the case, it won't see them.


            I've had a few conversations via email with Winfried Huslik, FMDiff's developer, since posting this thread here. I asked if he's more confident with Recovered files since FM 10. He said he doesn't feel so worried anymore about using an FM10 Recovered file as long as Recover reports no problems, and FMDiff sees no problems. In this case, if I loaded the Recovered file and remove the Recovered Library table, and then do the usual tests on it, as suggested by the FMDiff web site. It passes. The procedure, assuming this new Recovered file is now called the "Original", is to make a Compacted Copy and a Recovered Copy of the Original, and then use FMDiff to compare the Original with the Compacted copy, and then use FMDiff to compare the Original with a Recovered copy.


            Still, I refrain from using the Recovered copy. Maybe one day, when I get tired of seeing the Recovered Blob when doing my testing of candidates for Gold copies, I'll just switch to using a Recovered copy with the Recovered Library table removed.  Alternatively, I can go back to the version that had the graphic, delete it, check it out with FMDiff, and then, if it passes with no Recovered Blob, add all the changes I made previously, after deleting that graphic. Not sure at this point. Of course if I want to take the latter approach, I better do that soon, before I make too many changes to the solution.