Bug 1098 : Don't copy resource forks and extended metadata on OS X build
Last modified: 2010-06-05 09:52



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2008-12-09 13:47
not sure what the problem is: just downloaded processing-1.0.1.dmg om iMac 24" with OSX
10.5.5. Virusbarrier warns: corrupted file ... so I don't want to open this package. On earlier
versions of processing: no warning.
Additional Comment #1 From fry 2008-12-10 07:46
That sounds like a bug in VirusBarrier. It's not complaining that there is
a virus, only that the dmg is corrupt? The file is not corrupt, and we've
had thousands of people using the 1.0.1 release on the Mac without any problem.
Additional Comment #2 From rob_proc 2008-12-10 11:25
ok, Virusbarrier says only that the dmg is corrupt, no virus warning. I will try to report this to
the supplier Intego. Thanks.
Additional Comment #3 From rob_proc 2008-12-17 11:33
Received this answer from the support desk from Intego: This file is corrupted inside the
.dmg :


It seems the resource fork of the file is damaged.
You may try to open and save it into another file. The new file generated isn't recognized as
Or do it using the Terminal typing those 2 commands :
cp -X file filecopy
cp filecopy file

I have tried this and now Virusbarrier doesn't complain about a corrupted file.

Good service from Intego, no Virusbarrier bug and Processing seems to work fine with the
damaged resize.gif ... but I feel better now that I know what was going on.
Additional Comment #4 From fry 2009-02-19 18:19
Thanks for the followup. I've fixed the more fundamental problem (and
changed the bug title to reflect that) in the build scripts. Using -X has
cleaned things up. After all, we don't need 60KB of Photoshop gunk in a 92
*byte* GIF file.
Additional Comment #5 From fry 2010-06-05 09:52
this should be fixed with more recent releases, partly because ant won't
bother with the other resource bunk.