Search the Community
Showing results for tags 'uncomress'.
Found 1 result
-
Compression does not work as expected
Don Lee posted a topic in Retrospect 9 or higher for Macintosh
Retro 10.2.0 (221) engine on Mac OS X 10.8.4 on a Mac Mini. I have been having trouble with media set copies, and so have been very watchful of the operations that I do to ensure that the output is sound. I had a small media set, about 7.8 GB, we'll call it orig. I copied it to arch, with compression enabled in the script. The resultant media set was 2.2 GB, but had the requisite 203 files. I wanted to verify that the 2.2 GB was "enough" by running a script *without* compression enabled to "re-inflate" the data. I copied the copy to "zjunk" without compression, and the result had 203 files, and 2.2 GB. I then tried resetting zjunk, and copying orig to zjunk, which resulted in 7.8 GB and 203 files. I then tried copying arch (compressed) on top of the files already in zjunk, with options un-checked so that no duplicate elimination was done. The resulting zjunk was 406 files and 9.9 GB. It appears that "compression" is a one-way operation on media sets. un-checking the "compress" option in the script will NOT un-compress the resultant copy. It also appears that compressed, and un-compressed data can be "mixed" in a given media set. The media sets, therefore, have no "compress attribute". Is this as it should be? It would be nice to get more information on the compression. There are a few places where "amount saved" is put in the logs, but when estimating the amount of space/tape that will be required, that compression performance data can be really useful.
