🚀 go-pugleaf

>>I agree that it would be really nice if SpaceSaver kept a list of files
>>which were accessed, rather than relying on the Finder's "modification"
>>date, which doesn't necessarily change for applications.
>>
> 	We agree too - but that would take up disk space (since the MacOS
> does not store that info) - just the thing we are trying to save ;).  Would
> you (users) we willing to make that tradeoff?  Could we take up some of your
> precious disk space (say 50 bytes per file) in exchange for being albe to have
> access dates on files??

	I'd be willing to make the tradeoff.  More to the point though I'd be 
willing to make a much larger trade-off to keep lists of different files to be 
compressed so that I could decide on a file-by-file basis which files I wanted 
to compress and which I didn't.  Nothing against ANY transparent compressor 
here, but I'm still a little nervous about compressing data files.  I had 
one too many bad experiences with corrupted Compactor and StuffIt archives
in the past to fully trust any compression solution, transparent or archiving,
init, resource, or driver based.  (Again let me stress that this is only my own 
paranoia talking.  I have NEVER seen evidence of data loss with any transparent 
compressor.  Archiving compressors are another story.)

	Therefore I want to use transparent compression to 
compress only applications and SUPPORT FILES.  For example
I want to compress Microsoft Word documents that contain manuals for freeware 
or Readme files but not Microsoft Word documents that contain the latest, 
unreleased version of the FAQ.  And I don't want to have to reorganize my hard 
disk to accomplish this.   I don't use System 7 so labels aren't an option, and 
even if I did they're still too clumsy.  I want to tell StuffIt SpaceSaver or 
MDS or AutoDoubler or whatever to compress (and automatically decompress and 
recompress) File A and have it rememeber that in the future without worrying 
about the side effects this might have on any other file on my disk with 
possibly the same type, creator, label, and even contents.  No 
currently shipping utility let's you do this.  When I ran More Disk Space I 
compromised by just compressing applications, but that saved me substantially 
less space than if I had also been able to compress support files.



> 
>>It caused Kermit to crash when I tried to transfer a compressed file.
>>The solution? Label (or rename) the folder containing Kermit so it
>>won't be compressed. Move files to this folder before uploading. (When
>>you move a file into a folder labeled this way, the file is automatically
>>expanded.) 
>>
> 	Really?  I can't of any reason why it would crash trying to tranfer
> a compressed file.  Hmmm...

	Which version of Kermit was being used? I believe 0.98(40) was the last 
official and more or less stable release, but there are a number of betas of 
0.99 floating around the net of varying degrees of stability.  Some crash if 
you breathe on the monitor wrong.

--Elliotte