🚀 go-pugleaf

In article 17331@netcom.com, leonardr@netcom.com (Leonard Rosenthol) writes:
>In article <1k10gdINN5p@armory.centerline.com> chapman@centerline.com writes:
>
>I sent a similar responce to Scott via AOL, but for the net as well...
>
>>1) SS does not work well with CopyDoubler. 
>>
>	My understanding is that CD 1.0.1 should be much better behaved than
>1.0 and may work better with SpaceSaver.  However, you may find that other
>"finder speeder uppers" (SpeedyFinder7, CopyRIGHT, etc.) would also better
>serve your purposes and some even support copying SS files in compressed form.
>
>>2) "SpaceSaver Info..." from the SpaceSaver menu causes files compressed to 
>>SpaceSaver to revert back to standard Stuffit Deluxe icons. 
>>
>	I have heard this report before but have not been able to verify it
>ourselves.  I will, however, investigate it and you may also wish to check 
>into the possibility of an extension conflict.
I will email you my system configuration. I could try to track it down to an
init conflict also.

>	
>>3) No way to halt a timely operation. 
>>
>	That is because it would leave your files in an "inconsistant" state.
>If you move a folder of "small" files into a "big" folder, those files should
>definately be compressed - if you interrupted, then things could end up in
>a BAD stat (ie. you copy a folder of compress files into the System folder,
>and then interrupt the progress - WHAM - compressed files where they do not
>belong).
But you can already do this (I don't think "WHAM" is quite the word, unless something
catastrophic happens), by telling SS to skip the file it is currently working on.
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...

SS should be able to halt the current process and fix up this "BAD" state during
idle time 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??

>
>>Suppose you move a large unlabeled folder
>>out of a folder labeled "compress". You can get SS to skip some files, but you
>>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.

If the file doesn't have any designation on it, then you shouldn't do anything
to it. Leave it alone.

>
>>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).

>
>>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... 
>



---
                                  |
                    Scott Chapman | chapman@centerline.com
              CenterLine Software | (617) 498-3230
                   10 Fawcett St. | (617) 868-6655 (FAX)
              Cambridge, MA 02138 | (Centerline was formerly Saber Software)
                                  |