.sitx file format conversion to .sit

[Irisman]

HI,

I am trying to help a finnish guy to recover some TX802 patches from more than 20 years ago, in galaxy format. After very much hours of work without result, I asked him to send me a .sit file with a copy of the original data. He sent me a .sitx file, that I can´t open in my computers here, so I need some help.

Maybe any of you could help: the task is to decompress the .sitx file, and (of course, keeping the files data fork and so), create a .sit file with them, so I can open those files in my macos8 (or in Sheepshaver).


The file is already uploaded to the FTP, Irisman folder.

Thanks in advance,
J.

[DieHard]

I think StuffIt 7.0.3 from Garden does both sitx and sit... so you should be able to load that in SS and accomplish what you need

[IIO]

yup, v7 should be fine, but that requires 10.4 when i am not wrong ... sitx and classic OS is nada.

btw, i can only recommend anyone to use .zip for everything - and i mean in OS9, too! it is so much faster, and a bit less propertiary than this damned .sit crap.

[DieHard]

Please do NOT use zip here

Zip, Tar, and LHa do NOT support Mac OS resource forks, so please stick with SIT (or even Better SEA) for anything Uploaded here... this will ensure that the resource forks or each file that is archived together will be preserved...

Additionally, it is a good idea to also encode the compressed (SIT,SEA, or toast image) with MacBinary so that transferring it to various systems will preserve the resource fork of the compressed file and retain it's owner (creator) property. This helps the newbies that do not know how to manually expand the file or mount the image and simply double click it.

File Notes: Most of our files have been encoded into MacBinary format (.bin) so that the data and the resource fork of the file will not be damaged when storing the Macintosh file on a non-Macintosh system. After downloading, if the file does not automatically decode by double-clicking, we recommend opening StuffIt Expander and Selecting "File" and "Open" to decode the downloaded file. StuffIt Expander is included in every Mac OS 9 installation. Additionally once the app is open, check EDIT > PREFERENCES > INTERNET and "use stuffit expander for all available types"

[Irisman]

I think StuffIt 7.0.3 from Garden does both sitx and sit... so you should be able to load that in SS and accomplish what you need

Thanks, I´ll try that.   I read something in the net and found the same info: stuffit 7 for classic mac will open sitx files     sometimes the trees don´t let you see the forest

[supernova777]

u guys got to remember the timing of these things..
the sitx format was introduced.. *drumroll* around the same time as alot of other programs were being transferred to OSX
ie: 2003-2004
so naturally u would have to use a version of stuffit from this era
to have the functionality of extracting or creating .sitx

heres a thread on sit vs sitx
http://forums.appleinsider.com/t/22978/sit-vs-sitx
note the date: april 2003 4/10/03

.sitx correctly stores Unix permissions. That's the difference.

So I could use .sitx on my entire Applications folder (for example) and then when I unstuffed it all the permissions would be in place?

Good to know.

i would assume that the .sitx format has its origins in
the programmers making an attempt to match all of the
extra unseen features of using in combination, SIT + OS9
and bringing a similar featureset to those people
who had depended heavily on these features at the time...
making the transition more viable to continue working + archiving
in the same way with the combination of OSX + SITX
re: resource forks, permissions, metadata etc etc

using .sit on os9
and using .sitx on osx
will preserve the proper file attributes + unseen properties more eeffectively
there is no purpose for creating .sitx on os9 in order to move files to osx
.sit works fine for this purpose...

in summary:
.sitx would only be more usefull + beneficial over .sit if transfering an elaborate set of data/program files from 1 OSX machine to another with the goal of maintaining these settings

also
using a more recent-ish version of stuffit should allow u to extract these files and may also facilitate some type of file properties/permissions conversion from osx perms to os9 perms...
(im guessing)

[DieHard]

I did not realize that 7.0.3 could only create sitx and not extract them correctly... tried your file and just got a tree with all files 0 KB.... guess that is why I don't use sitx (I also remember there was a cool program that worked under tiger called "unarchiver" that uses sit,sitx and others.... at any rate in the OS 9 world guess it's wise to stick with SIT,SEA, or toast images as we always have


Irish...

Your file has been downloaded and re-archived and uploaded as both a "zip" and "Sea.bin"... take your pick, both will open under OS9

[supernova777]

u should be able to extract .sitx properly using the final version of stuffit for os 9
they were still messign with that probably if u have a version that is prior to 7.5.x
but i mean.. .sitx - basically means stuffit for X
u would be better off to extract a .sitx on an osx system (powerpc era? intel?) and rearchive ^^ like it seems diehard has just done

they probably made further updates to the .sitx format in the years that followed which would account for the file extraction problems

[DieHard]

Think your right Chris, I am sure a "SITx" (let's say ver 1.0) Made with 7.0.3 would extract peachy under Mac OS 9... but a "SITx" created later under OS X (rev 3) sends StuffIt 7 into a tail spin when trying to extract under OS 9... so conclusion... Not all SITx files are equal since the content (as you mentioned) may have OS9 resource forks or OS X file permissions and even the various revisions may have changes in the formatting.

[Irisman]

Irish...

Your file has been downloaded and re-archived and uploaded as both a "zip" and "Sea.bin"... take your pick, both will open under OS9

Thank you very much for!!   

Anyway, interesting conversation with this sitx thing

Ah, and its "Iris(man)" not "Irish(man)" 

[DieHard]

Sorry Iris... my bad... just call me"Dickhead"

[Irisman]

Sorry Iris... my bad... just call me"Dickhead"

LOL!! 

[IIO]

somehow it is funny (and says a lot about how the industry treats us) that after 15 years none of us knows everything about it, and were are all still experimenting and discussing.

for example i´ve never noticed that there was .sitx already in classic. (luckily, as it seems, because processes which are not downward compatible when they upgrade them, should be avoided at all cost)

otoh i wonder what you guys are doing with that binary encoding: i´ve never seen any file loosing its resource fork or breaking in some way only because it wasnt .hqx or .bin or something. and also not because it was a zip instead of sit.

the requirement of this "bin" stuff must have been present for System 6 times, where linux servers were not knowing of other filetypes or didnt allow unknown extensions.

today, i believe the more useful idea is to attach osx-like file extensions to files, because the use of OS9 files outside of OS9 is most likely in OSX 10.4-10.5 (and not in early red hat or novell^^)

for example it makes sense to add .img or .toast to image files. OS9 might not need it, but you can now easily see from its name what it is even when the type is ? or something odd.

that is also why i switched to .zip around 2000, btw. because when i copy, pack or unpack huge amount of files, i do that in OSX anyway, simply because it is like 4 times faster in OSX.

[DieHard]

110... I understand where you are comming from... but we are trying to make all items usable for those who have systems that are OS 9 only, that is why we will stick to the convensions that are tried and true under OS 9.

Binhex (.hqx) encoding is long since outdated was mostly for preserving file forks when sending email attachments. Macbinary III (.bin) is our standard encoding here, since after testing our new file storage system (ADrive) is was apparent that indeed, aspects of the compressed archive or file was lost (like the "creator" and "type").  This was NOT the case with our old "Apache style" FTP storage that we used under GoDaddy... all StuffIt archives that were downloaded were still recognizable as Creator "SIT!", under ADrive they were not.

So, since we do not have a Novell File Server (with Mac Name Space loaded) as you mentioned, we cannot rely on any paid Web Online storage to store our precious OS 9 archives and files and recognize all metadata in the resource forks.  We have established this as our standard... first make SIT, SEA, IMG, SMI (Shrinkwrap self mounting) or toast and then MacBinary encode... this will ensure that no Matter what file structure exists on the Online storage server we will not have to "redo" our archives.  And if we change the service in the future, we are ready.  This has consumed many extra hours of my life, but I feel the benifits are obvious.  Even though many users have OS X units also... some do not... and what is the sense of having rare stuff for OS 9, that is not usable by all ?   

Please do NOT confuse this standard with "OSX-a-Phobia".  We needed a standard, and we chose one... if we let analysis paralysis take over we could have all debated on the right approach for the archives, but I rather simply pick what works and then make some music... all I can say is that we did not do all this extra work, simply to make extra work... we did it to take all the confusion out for the newbie musician who does not want to study file compression algorithms... rather then getting technical... it is simple... get TOAST for OS 9 and Stuffit expander for OS 9 and you are done... and can enjoy everything

[Irisman]

it is simple... get TOAST for OS 9 and Stuffit expander for OS 9 and you are done... and can enjoy everything

Glad to read so simple line for newbies

[IIO]

"Please do NOT confuse this standard with "OSX-a-Phobia""

no no, i dont, dont worry. i am really happy about a place which is strictly OS9 only.

but i used .zip in mac os 9 for years, too, you know? and i´ve seen millions of people sharing files using just .sit and not .sit.bin and it worked out fine. so i am not really convinced about this idea yet.

of course i am not discussing what you are doing here, what is done is done and i am not going to argue about it. i was more on the "in general" layer.

now lets come back to the problem of the OP and you will see what i mean: someone sent him a crappy .sitx format, which he can not open in OS9. since its .sitx, and from a musician, it probably comes from OSX. if he would have received a .zip file instead, he could have opened it in OS9 with stuff it. (attention, it is getting philosophically now.) the OSX person was ignorant using a format which only works for him. instead of choosing a format which would also open in classic and in windows. now lets dont do the same ignorant thing and tell the OSX buddy he should send us a .smi.bin file for us to use in classic! the OSX guy doesnt have shrink wrap 3.5.1 on his intel mac and probably would first need to find out how to create .bin with a third party app. he has BOMArchivehelper.app in OSX, which creates archives that unzip perfectly on OS9, OSX, windows, and linux, and that should be his first choice.

btw, yesterday i downloaded http://macos9lives.com/smforum/index.php?topic=1035.0 , just to see what i is. when i extracted that file in OSX using stuffit 12, i got a 300 mb folder out of the 450 mb archive containing only the /applications folder...

oh yeah, your filehost, adrive .. that seems to be actually usable compared to most others, congratulations for this choice. but i believe some day we should get a little server together and run some of the protocols there most of you probably know ... and miss ... like i do.

 

[IIO]

hmpf.

[DieHard]

Last post I will make about this...

In the case where the downloaded file is a stuffit archive... then encoding (.bin) is not needed if the user know to either drag it on top of StuffIt expander or open StuffIt and uncompress it manually... so it is basically re-dun dent since the stuffit archive itself will protect all of the contained files resource and data forks, but I am encoding everyfile (including SITs) for a convention/standard.... if the file being downloaded is an installable application file then the encoding (.bin) will ensure that the resource fork is not striped off in the upload/download process and this is where the encoding becomes more critical.

As far as you being convinced about zips... I have seen many Mac OS files get ruined... but maybe if you see it from another source you will be more likely to take such things on faith...

FROM THE MACINTOSH GARDEN

Storing MacOS 9 files in zip will destroy them, because MacOS 9 and older store also an invisible file with its resource fork informations, which will be lost, if saved in zip file format or even opened on a PC. The Resource fork stores the file creator (application the file has been created with) and some other informations.

Thus, it's not recommended to expand the files with Stuffit for Windows. For more information please see http://en.wikipedia.org/wiki/Resource_fork

Also, there are different ZIP formats for storing Mac resource forks. For instance, if you use OS X's default "Create Archive" it will create a __MACOSX folder in the ZIP for the resource fork that I guarantee no classic unarchiver will know what to do with.

[IIO]

Storing MacOS 9 files in zip will destroy them, because MacOS 9 and older store also an invisible file with its resource fork informations, which will be lost, if saved in zip file format or even opened on a PC. The Resource fork stores the file creator (application the file has been created with) and some other informations.

i believe that the marked quotes would not stand a validation. except when you read it in its original context (which was referring to unzipping on windows OS)

[MacOS9Lives.com]

OK I lied... i will post again...lol

OMG 110... I am starting to feel like I am arguing with my wife... who can be a "non-believer" at times...

Let's forget about Windows, if you open StuffIt 7.0.3 under OS 9 and go to Preferences then you will see a preference under "MacBinary" that spells it out... It is referring to using "MacBinary" encoding on every file that gets put into a ZIP archive to preserve the resource fork... so as it explains...

The ZIP,Tar, and LHa formats do not support MacOS resource forks. This option uses the MacBinary format for storing MacOS files within a Zip archive.

You can also note, this option does not mention "SITs" since its archive file structure will always preserve the forks, and thus would be unnecessary to encode the files being stuffed.

So, basically, unless the Alladin guys were smoking big piles of Ganja, which they probably were anyway; they saw fit to included this option so that when making ZIP archives the fork would not get stripped if you were planning to share the ZIP archives with other Mac OS users.

One option that we could have used, when creating our archives in the download boards, was to set this preference on "always" and make Zip archives... basically this would ensure that each file gets "encoded" or encapsulated with a safe blanket of MacBinary and then gets zipped up with all the other encoded files to form a "Mac OS 9 friendly" ZIP archive.  Upon decompression there are 2 automatic steps... decompress the archive and remove (decode) MacBinary from each file that gets extracted.

If you still want to use Zip, then so be it ... you are making my balls hurt