[comp.sys.mac.system] Severe BUG in AutoSqueeze!

thomas@duteca (Thomas Okken) (02/22/91)

When you duplicate a file in an "automatically compressed" folder in the Finder
(using the Duplicate command in the File menu, or by moving a file out of an
"automatically compressed" folder while holding the Option key down), the copy
will be truncated.
Watch out for this: you get no warning that this is happening, but when you open
the file, the last half will be gone!

Apparently, what happens is this:
1. The Finder checks the file size in order to determine the disk space needed
   for the copy. The file size that it gets is the *compressed* size.
2. The Finder opens the file.
3. AutoSqueeze kicks in now (due to a patch on the _Open and _OpenRF traps),
   and uncompresses the file.
4. The Finder creates a new file and opens it.
5. The Finder copies the original data and resource forks to the new file,
   copying just the number of bytes these forks had in their compressed states.
   Since compressed files have no resource forks, the copy will (probably) have
   a truncated data fork, and no resource fork at all.
6. The original and the copy are closed.
7. The original is recompressed (or the temp file that was used is discarded).

Note that it does not matter whether you copy into another compressed folder or
not. The problem is that the Finder simply uses the wrong file size for the
copy.

This problem is not unique to the Finder. Copying from the MPW Shell suffers
from the same problem, and there may well be other applications having trouble
with this. Applications that do not keep files open while the user is editing,
and that implement 'Save As...' as a file copying operation, will probably
also have this problem.

As things are now, this bug is totally unacceptable, IMHO, and should have been
caught before release. A fix should be easy: patch all traps that get file info,
and give the uncompressed size. A drawback would then be that 'Get Info...' in
the Finder shows the same size for the compressed and uncompressed file, but
the advantage of a *reliable* utility should outweigh this by far.

BTW, anyone know an e-mail address of Dawson Dean? I'd like to get this to him
quickly, but I don't know how!

 - Thomas (thomas@duteca.et.tudelft.nl)