[Date Index] [Thread Index] [Author Index]
Re: What's in the " .mb" files????
In article <DIECnt.MHG at wri.com>, J.P. and/or Valerie Purswell <purswell at netplus.net> wrote: >I recently made the connection between deleting apparently unnecessary ".mb" >files and my notebooks turning up with all inactive cells. When I opened up >these .mb files in mma, there appeared to be only a line or two of code in an >inactive cell. Nevertheless, the .mb files take up a good deal of disk space. > >Must be a lot of information that's not directly viewable in these files. Can >someone give me an idea as to what exactly is stored in these files and why >mma puts information it needs to evalaute a notebook in a different file? The .mb files contain the information in the .ma file but in binary form, which enables a notebook file to be opened faster. To my knowledge, there shouldn't be any info in the .mb that isn't recoverable from the .ma, and you should be able to freely delete those files if they're taking up too much space, at the price of slower opening of your .ma files. I can't believe that deleting a .mb would change the active/inactive status of any cells, because when you transmit a notebook to another platform, all that gets sent is the .ma file. --- Mac users only, Windows users stop reading here --- Macintosh users note: if you've got some gigantic notebook files that are taking up too much space, the culprit is usually screen images for the graphics in the file, which are stored in the file's resource fork. If you have a resource editor such as resEdit you can open the resource fork and delete those resources. (They all start with the letters "OM".) For example, I have a file with some 3-D graphics in it; the data fork of the file (which contains the Postscript descriptions of the graphics) is about 900K; the resource fork is an *additional* 2.5M. Of course, if I delete those resources then the front-end will have to re-render all of the postscript the next time the file is opened. By the way, don't confuse deleting the preview images with front-end commands such as Graphics->Convert to Bitmap. In the latter case, information is lost and you cannot get the original postscript image back except by starting the kernel and re-evaluating the graphic commands that generate those images. One last caveat: if you open the resource file and see "PICT" resources, don't delete those unless you're prepared to re-evaluate the associated graphic commands. PICT resources are used to store a graphic image when you choose Graphics->Convert to PICT. The original PostScript is wiped and instead the cell contains only the resource number of the PICT that is created. If you delete a PICT, the corresponding graphic will disappear from the notebook file. A possibly simpler approach, depending on your point of view, is to compress files that you don't use very often using a file-level compression utility. I've found that compression ratios of 10:1 are not at all unusual for notebook files with lots of complicated graphics. Dave Wagner Principia Consulting (303) 786-8371 dbwagner at princon.com http://www.princon.com/princon