Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1995
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1995

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: What's in the " .mb" files????

  • To: mathgroup at smc.vnet.net
  • Subject: [mg2579] Re: What's in the " .mb" files????
  • From: wagner at bullwinkle.cs.Colorado.EDU (Dave Wagner)
  • Date: Mon, 27 Nov 1995 21:30:39 -0500
  • Organization: University of Colorado, Boulder

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


  • Prev by Date: Re: Problem: Plotting list of {InterpolatingFunction[]}
  • Next by Date: RE:Labeling Lines on a multiple plot
  • Previous by thread: Re: What's in the " .mb" files????
  • Next by thread: Re: Re: What's in the " .mb" files????