🚀 go-pugleaf

In article <1k3ipfINN37u@armory.centerline.com> chapman@centerline.com writes:
>In article 17331@netcom.com, leonardr@netcom.com (Leonard Rosenthol) writes:
>>In article <1k10gdINN5p@armory.centerline.com> chapman@centerline.com writes:
>>
>>>3) No way to halt a timely operation. 
>>>
>>	That is because it would leave your files in an "inconsistant" state.
>
>Allowing uncompressed files in a folder marked for compression would also
>be a similar "BAD" state, and you allow that as well. This may indeed be an
>incosistent state but it can be more desirable than waiting many minutes while
>many files get altered...
>
	Uncompressed data in a compressed folder is not a big deal (this would
be the same as having a "big" file in a "small" folder), but the other way
around is not so good since there are some "big" folders (like the System)
where compressed files could be a no-no.

>SS should be able to halt the current process and fix up this "BAD" state 
>during idle time compression.
>
	You are assuming that every user has "idle time compressioin" turned
on.  Unlike other competitive products, we give you the choice of using 
idle time, or manual/explicit or both types of compression.

>The "BAD" state is not problematic. SS will still uncompress the files (even though
>they are in an uncompress folder) won't it? or are the files damaged??
>
	SS will still do all the right things!

>>
>>>Suppose you move a large unlabeled folder
>>>out of a folder labeled "compress". 
>>>cannot get it to stop the uncompress operation. 
>>>I still do not understand why it is uncompressing the files anyway, 
>>>I did not move them to a folder labeled "uncompress"...
>>>
>>	No you did not move them into "uncompress", but you moved them out
>>of "compress" which is almost the same.  By moving them out of "compress" the
>>files no longer had any "attributes" that would designate them as being
>>compressed and as such they were expanded.
>
>What? If you compress a file (by selecting compress from the SS menu) the 
>resulting file will also not have any compress designation, but it doesn't 
>uncompress it.
>
	That's correct, but is also a different case then what you described
above.  A file compressed via Magic Menu has an "attribute" so it is maintained
when copied - just like copying a small folder from one "untagged" folder to
another will keep it compressed since the attribute goes with it.  

	When you moved an "untagged" (unlabeled) folder from a "small" folder
to an "untagged" area, it lost it's attribute of compress (since that was a
factor of it's environment) and so it was uncompressed.

>>>4) I couldn't not figure out how SpaceSaver works with nested folders. 
>>>
>>	It's all pretty simple.  "BIG" (uncompress) always takes precidence
>>over small since that way you can not put compressed files into a "big"
>>folder (like the system folder).
>
>I think you are right, that is the behavior I saw, but I don't recall it as
>eloquently described in the manual. Anyway, I also think this behavior is wrong
>There are some folders in the System Folder which I would like to compress
>(After Dark Folder comes to mind).
>
	We considered allowing users to compress file/folders in the System
folder early during development, but found that it caused TOO many problems
when users would compress things that needed to uncompressed BEFORE SpaceSaver
loaded.  Therefore, to alleviate any chance of the user "shooting themselves 
in the foot", we consider the System folder (any active one on any disk) to
be "big".

	FWIW: With the latest version of After Dark (Star Trek) you can alias
the modules folder and compress it ouside the System folder - JUST MAKE SURE
to load SpacSaver before After Dark.

>>
>>>5) No way (in idle-time compression) to compress files which have not been
>>>USED (as opposed to modified) in a given amount of time. It would be great to
>>>have my infrequently used applications remain compressed, but the ones I do 
>>>use on a day-to-day basis remain uncompressed.
>>>
>>	NONE of the compression software does this since the Macintosh OS does
>>not store this information - only the last modified date.  We could maintain
>>this info ourselves, but that would require a (possibly HUGE) file to be 
>>created to store that info and since we are trying to save space, putting
>>a large file on your disk wouldn'[t make much sense ;).
>
>Too bad, that certainly is the behaviour I want though... 
>
	Would you be willing to give up anywhere from a couple hundred K to
a couple of megs of disk space for the file to store this info??  Seriously,
if enough people feel that they are willing to take the trade off of getting
"used" vs. "modified" (which is the right way, I agree) in exchange for loss
of disk space, we wouold be willing to consider it.

-- 
-----------------------------------------------------------------------------
Leonard Rosenthol			Internet: 	leonardr@netcom.com
Director of Advanced Technology		AppleLink:	MACgician
Aladdin Systems, Inc.			GEnie:		MACgician