Way to make 'modifiable-zip' file-system? (DiskDoubler for OSX?)

Jim Witte jswitte at bloomington.in.us
Thu Aug 16 18:07:03 PDT 2007


Hi,

   I'm not sure whether this should go on this list, on darwin-dev,  
or no-where at all, but it's rather odd.  I know that disk space  
today is ridiculously cheap (I remember when a 256 *mb* HD was  
considered "big" and 1GB was "huge"..  Not that long ago either :))   
But I look at a lot of the sample codes (I sort of collect sample  
code :), which often is something like 1.1 MB expanded, but only 200K  
when zipped (or DMG'd), and always think it would be nice if there  
were some way I could work with it, bit keep it stored in a  
compressed format.

	I can imagine 2 ways to do this, assuming the DMG is not R/W (can  
they be, and still be compressed?)  One would be to decompress the  
file to a ram disk (*aheh* memory resident FS I think), and then  
recompress.  The other would save memory and maybe space at the  
expense of (maybe) time and a lot of complexity (I think).  That  
would make an FS that would LOOK like the contents of the compressed  
files, and actually read file files and uncompress them on-the-fly  
(is it possible to uncompress just part of a zip archive, or must it  
be un-compressed 'in sequence'?), but then any changes you made would  
either make a NEW file that would be compressed (onto a separate  
'diff' archive, either compressing the entire changed file, or just  
compressing a diff version of it.  Then you'd have TWO files, the  
original and the 'diff' archive, which would probably be bundled  
together.

	Is this feasible to do (or is there something to do it already)?   
I'd imagine the first idea (uncompress to memory disk and then re- 
compress) would be easiest, but would also mean rewriting the entire  
archive, and not just the changes.)  I guess this is also kinda like  
what I've read about how Time Machine will work - except that it's  
not for backup only, it's a main FS.

	Aside: This kinda similar to how the Newton did it's memory  
management: a "frame" accessed from a package was RO and still in  
virtual memory on the slow RAM cards, but if it was modified, it was  
copied copy in DRAM was RW format.  The system transparently did the  
copying and access of the correct part of the memory - DRAM space or  
the high-address virtual package store space.

Jim Witte


More information about the MacOSX-dev mailing list