Macintosh Users:

Correct me if I'm wrong, but trying to share a DiskCopy or ShrinkWrap ".img" or ".smi" file through Limewire could be absolutely pointless.

The ".img" file format, as well as the ".smi" self-mounting variety, each contain a small amount of critical resource fork information. It's possible that this info won't be preserved during the download. This is because Wintel boxes (which could handle the file somewhere along the line) don't understand what a resource fork is, and will consequently sever the file. They can only understand, and thus preserve, the data fork. The end result will be a corrupt disk image file that won't mount.

If you want to share a ".img" or ".smi" file, please be sure to encode it in order to preserve the resource fork information. In other words, before sharing, convert it to a Stuffit Archive file (".sit"), or encode it into a MacBinary (".bin") file or a BinHex (".hqx") file. Alternatively, if you're using OS X, you could create a ".dmg" file.

FYI, Macs use a dual "forked" file structure. Every file on a mac has both a "data fork" and a "resource fork" where information in the file is stored. Most document files, like .mp3 files, Microsoft word .doc's, etc. have all of their info in the data fork, and the resource fork, while present, is empty. So sharing .mp3 files is quite easy. Application files often contain resource fork info such as menus, windows, and icons that are used in the Finder. Unfortunately, ".img" files, ".smi" (self-mounting-image,) and ".sea" (self-extracting-archive) all have a tiny amount of resource fork info that is a critical part of the file, and this results in "corrupted" files.

Hope this helps...

Thanks....and keep sharing!