Do StuffIt 5.5 archives encode the resource fork safely for transfer to a non-Mac ?

[MrFahrenheit]

I'm trying to understand the necessity to BinHex (.hqx) files before uploading to a website.

In the old days, we always downloaded a .hqx file, that we decoded, which contained a compressed archive, often .sit. At some point, it seems that StuffIt changed its compression/encoding to account for uploads to non-Mac computers. Is this correct?

I want to know, is there anything lost when compressing a set of files with StuffIt 5.5 and then uploading that .sit file to a non-Mac? If not, when did this feature begin?

I have many thousands of files that I have stored in StuffIt archive format (.sit) on pre-OS X Macs going back to 1995. I would like to clarify whether I need to unstuff them, and then stuff them again using a newer version, to avoid corruption issues. Or whether I can just upload them (once I know what version was used to stuff them).

I want people who download the files to be able to extract them easily, as well.

I kind of wish some standardized file format would be established for the archive sites like Macintosh Garden and Macintosh Repository. If everyone just had an ISO mounter extension, and all of the downloads were ISO it would solve so many problems

 

[Phipli]

Hey MrFahrenheit

I believe the change happened at version 5. Like you say, before version 5 stuffit files had a resource fork, after, they didn't.

Regarding your comment "whether I need to unstuff them, and then stuff them again using a newer version", personally, I say no. Because you should bin / hqx the older sit files. The reason I say this is because with default settings a) you can't decompress with a sit v.5 file on a 68000 and b) it just takes too long on any 68k computer.

I kind of wish some standardized file format would be established for the archive sites like Macintosh Garden and Macintosh Repository. If everyone just had an ISO mounter extension, and all of the downloads were ISO it would solve so many problems

Again, I haven't seen an iso solution for 68000, or a good one for 68k. I use Toast... but it is often a bit of a bodge and I have to guess the block size and hope.

Genuinely I believe the best solution is to do what we used to do - sit + bin. The reason? Because that is what all the common period software expects. Stuffit Extractor and Compact Pro will both extract a sit in a bin.

Version 5 is great that it works when uploaded, but in a way it is a bad thing - it has made people think they can upload any sit and resulted in lots of trashed uploads.

The most important thing is to always test your uploads. Redownload what you upload and test it on period hardware.

Also, CD-Rs are amazing for transfering and I still buy 100 disk cakes for when I don't have ethernet cards in a machine.

 

[Phipli]

Further to the above - in Drop Stuff there is just a checkbox in preferences, checking it and it always automatically ".bin"s your archives. We should always .bin any files for upload if there is doubt - if nothing else it preserves file type and creator, again saving faff.

 

[twelvetone12]

I thought that BinHex was used to transmit files over ascii-only channels, i.e. a chat, since it encodes the file as a hexadecimal chars encoded in ascii.

 

[cheesestraws]

I thought that BinHex was used to transmit files over ascii-only channels, i.e. a chat, since it encodes the file as a hexadecimal chars encoded in ascii.

Yes, it was: sit.hqx was largely to get around misconfigured FTP servers that would eat non-ASCII content, at least as I remember it, as much as for combining the two forks.

 

[Phipli]

I thought that BinHex was used to transmit files over ascii-only channels, i.e. a chat, since it encodes the file as a hexadecimal chars encoded in ascii.

It is also a way of converting a dual fork resource + data file into a data only file, which prevents DOS/Win/Unix/Linux stripping the resource fork.

 

[cheesestraws]

It is also a way of converting a dual fork resource + data file into a data only file, which prevents DOS/Win/Unix/Linux stripping the resource fork.

Yes, but that's not the main reason it was used to wrap stuffit files, at least as far as I remember.

 

[MrFahrenheit]

I thought that BinHex was used to transmit files over ascii-only channels, i.e. a chat, since it encodes the file as a hexadecimal chars encoded in ascii.

Isn’t that more uuEncode than BinHex?

 

[cheesestraws]

Isn’t that more uuEncode than BinHex?

BinHex was more popular in Mac-land because it also joined the forks and metadata together—otherwise you'd have had to do something like macbinary then uu. And this usage was generalised to Mac files that didn't have resource forks also.

(going back to your original question: my personal usage recently has always been just to use SIT 5 files without any other encoding and it's been fine, but I don't know if there's an edge case waiting to trigger in that)

 

[Phipli]

Yes, but that's not the main reason it was used to wrap stuffit files, at least as far as I remember.

I think it depends on the environment you were in - this is all we used it for.

 

[MrFahrenheit]

Hey MrFahrenheit

I believe the change happened at version 5. Like you say, before version 5 stuffit files had a resource fork, after, they didn't.

Regarding your comment "whether I need to unstuff them, and then stuff them again using a newer version", personally, I say no. Because you should bin / hqx the older sit files. The reason I say this is because with default settings a) you can't decompress with a sit v.5 file on a 68000 and b) it just takes too long on any 68k computer.


Again, I haven't seen an iso solution for 68000, or a good one for 68k. I use Toast... but it is often a bit of a bodge and I have to guess the block size and hope.

Genuinely I believe the best solution is to do what we used to do - sit + bin. The reason? Because that is what all the common period software expects. Stuffit Extractor and Compact Pro will both extract a sit in a bin.

Version 5 is great that it works when uploaded, but in a way it is a bad thing - it has made people think they can upload any sit and resulted in lots of trashed uploads.

The most important thing is to always test your uploads. Redownload what you upload and test it on period hardware.

Also, CD-Rs are amazing for transfering and I still buy 100 disk cakes for when I don't have ethernet cards in a machine.

So if I have older 68k software, I should use StuffIt 4 and then .bin (or .hqx - which is the same, right?)

I’ve been testing my uploads by downloading in Mac OS 9 in Sheepshaver on Windows 10. I download using Windows Chrome to an NTFS volume and copy into Sheepshaver for testing, in the hopes I can weed out any corrupted files by others doing the same.

Has anyone tried Mar? It’s a tar format rewritten for 68k and PowerPC Mac’s. It encodes both forks safely, and preserves all file attributes. It’s quite fast on even 68k Mac’s.

 

[Phipli]

So if I have older 68k software, I should use StuffIt 4 and then .bin (or .hqx - which is the same, right?)

I think that is a good solution. It puts a little bit more work on the prep side but makes download/transfer simple and quick. I believe .bin and .hqx are the same or similar, but in truth I'm not certain. I've always treated them the same.

I’ve been testing my uploads by downloading in Mac OS 9 in Sheepshaver on Windows 10. I download using Windows Chrome to an NTFS volume and copy into Sheepshaver for testing, in the hopes I can weed out any corrupted files by others doing the same.

I think you are much more thorough than some, I don't think you'd have started the thread if you weren't

Has anyone tried Mar? It’s a tar format rewritten for 68k and PowerPC Mac’s. It encodes both forks safely, and preserves all file attributes. It’s quite fast on even 68k Mac’s.

I haven't, and I don't want to say that change is bad, but my only observation is that the advantage of a .sit.bin is that Stuffit Extractor came on many system disks and installs by default (not on the older systems, but on a lot of later stuff from 7.5.*(??) onwards). It takes a lot to outweigh the advantages of the method being already in place.

 

[jessenator]

You could be a chaotic neutral (evil?) And do a non self extracting CompactPro format : P

I kid, but I've wondered about this as well. Thankfully, I don't have any 000–030 Macs anymore, but it's definitely something with considering.

 

[LetraStudio]

You could be a chaotic neutral (evil?) And do a non self extracting CompactPro format : P

Sounds fine to me

 

[Phipli]

You could be a chaotic neutral (evil?) And do a non self extracting CompactPro format : P

I kid, but I've wondered about this as well. Thankfully, I don't have any 000–030 Macs anymore, but it's definitely something with considering.

I wish there was some kind of self extracting upload safe file, but there can't be because anything will lose its type/creator.

It does make me sad how CompactPro seems to have stopped being used.

 

[Crutch]

Hey, there is some big confusion in this thread between BinHex (.hqx) and MacBinary (.bin).

MACBINARY and BINHEX ARE TWO DIFFERENT THINGS
(sorry for yelling )

BinHex (.hqx) turns everything into ASCII for use uploading to old BBS’es etc which only like ASCII. Similar to UUencode. It increases file lengths by 50% on average.

MacBinary (.bin) combines resource fork, data fork, and type/creator info into a single binary file suitable for upload or use on modern OS’s. It is not ASCII-only and does not increase file lengths.

There is no reason to ever use BinHex (.sit.hqx or similar) in the modern era, ever. “.bin” files are not BinHex files, despite the confusing nomenclature.

MacBinary however is always recommended

 

[LaPorta]

I use StuffIt 1.5.1. Then, almost any Mac can open it, and you don’t have compatibility issues when saving in newer formats.

 

[Phipli]

Hey, there is some big confusion in this thread between BinHex (.hqx) and MacBinary (.bin).

MACBINARY and BINHEX ARE TWO DIFFERENT THINGS
(sorry for yelling )

BinHex (.hqx) turns everything into ASCII for use uploading to old BBS’es etc which only like ASCII. Similar to UUencode. It increases file lengths by 50% on average.

MacBinary (.bin) combines resource fork, data fork, and type/creator info into a single binary file suitable for upload or use on modern OS’s. It is not ASCII-only and does not increase file lengths.

There is no reason to ever use BinHex (.sit.hqx or similar) in the modern era, ever. “.bin” files are not BinHex files, despite the confusing nomenclature.

MacBinary however is always recommended

I wasn't sure - I always made .bin files, but .hqx were treated exactly the same way if I got them.

 

[Phipli]

I use StuffIt 1.5.1. Then, almost any Mac can open it, and you don’t have compatibility issues when saving in newer formats.

But you have to convert them into something other than a .sit to upload them because they have a resource fork.

 

[Crutch]

Right. StuffIt 1.5.1 + MacBinary (.sit.bin) is a good solution.