Mac OS 9 Lives
Mac OS 9 Discussion => Software => Topic started by: Irisman on May 27, 2014, 02:29:15 PM
-
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.
-
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
-
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.
-
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"
-
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 ;)
-
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)
-
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
-
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
-
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.
-
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)" ;)
-
Sorry Iris... my bad... just call me"Dickhead"
-
Sorry Iris... my bad... just call me"Dickhead"
LOL!! ;D
-
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.
-
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 :)
-
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 ;)
-
"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.
-
hmpf.
-
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.
-
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) :)
-
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
-
HI,
Just some info: I installed the Stuffit 7 from the garden, and it could not open the .sitx file (probably created on macos x). This was advised before here, so I confirm it.
Thanks for help!! :)
-
OK I lied... i will post again...lol
yeah i know how that feels.
well, from what you say alladdin has put .zip options in stuff it deluxe for mac OS 7-9 but noone can use it ... because it brakes files ... unless you find a special place its in prefs where you can check "preserve resource fork" or something. i know that alladdin is pretty dumb, but probably not that dumb? :)
man, i really want to go back to the classic times, where 90% of all musicians and graphic guys used mac and you were JUST SHARING FILES by drag and drop from one studio to another ... and not all that modern hassle with images, archives, encryption, and central hosting or buffering in the internet.
-
man, i really want to go back to the classic times, where 90% of all musicians and graphic guys used mac and you were JUST SHARING FILES by drag and drop from one studio to another ... and not all that modern hassle with images, archives, encryption, and central hosting or buffering in the internet.
Well, at least we have this place... it may not be much in this crazy modern world... but it still has its purpose; The tools may be old, but plenty of new, excellent, music can be made with the forgotten gems we have here :)
-
thats exactly the point. while others have upgraded to nuendo 6.5 and its - for the 7th or 8th time - "enhanced AAF import", i have switched to creating custom software during the last ten years so that i now have polyrythm, nonlinearism, and thousands of exotic scales at my hands.
so, did someone helped the OP with his sitx file? if yes, then someone should close the thread.
-
the only way to convert .sitx to .sit is to boot into OSX
use the appropriate .sitx compatible Stuffit Expander to decode the contents,
at which point u can create a new .sit file (if you have DropStuff, with preferences set to create .sit instead of .sitx) check in preferences for anything to do with making it backwards compatible i think there might be an opion for this
-
one last comment.. im pretty sure the reason u can even use .zip in mac os 9 was for the purposes of transfering files *FROM MACS* *TO PCS*
"DropStuff" (part of stuffit deluxe 2010 for snow leopard) includes the option to "make Zip"
but it also includes the option to "binhex"
i dont think its possible to create a .sit file with this app..
i think it only does .sitx
-
like i commented on another thread (see http://macos9lives.com/smforum/index.php?topic=2472.msg14127#msg14127)
it is possible to create .bin files from mac os x 10.6
by just dropping to terminal and using the command : "macbinary encode -v filename.ext"
i used another app called DropDMG, set in preferences to create OS9 compatible disk images (.img NDIF legacy) once its created the .img file i then can use the terminal to macbinary encode.. and the result is... opens perfectly on mac os 9;)
-
so, did someone helped the OP with his sitx file? if yes, then someone should close the thread.
I had the same problem as OP and I was looking for a solution. I found this thread and tried stuffit deluxe 7.0.3 on mac os 9.1 and it worked.
-
thanks for feedback. yes, for some sitx files it works. but only with OSX you are on the safe side.
-
It worked in OSX except that it lose the resources of the extracted files so they were unreadable back to os9. Maybe it could have worked with OSX Leopard and prior because of classic ?
I guess I was lucky ;)
-
not because of classic, but because of HFS eventually.
i use stuff it deluxe v10 and v13 on PPC and never had any issues.
(but of course i hate the format for beeing stuff-it exclusive. rar and zip is what you want to see in OSX.)
-
The oldest OSX system I have is Snow Leopard. I wonder : do know you what is the last OSX that handled correctly macOs ressources fork ?
-
in theory it should work with post-HFS disks, too. but it depends on what you do (archives, network protocols)
sitx is a nonsense format made specifically for jpg/mpeg files.
but i would think that stuff it in mojave would warn you when there is a resource fork in a file which cant be written to disk without corrupting the file.
regarding MacOS9 - that only works when the archive file has been put in "compatibility mode" (most sitx files were not, because then it is without the new features such as jpg supprt or encryption)
-
try unstuffing onto an HFS+ usb stick or disc image
-
Wow !!! Very nice trick !!! I'm currently waiting for mSSD PATA adapters to put in my Wallstreet and my 1400c but for now I use CFCARDs as hard drive. In High Sierra I tried to unstuff directly on these CFCARDs with an USB adapter and it works ! No ressources forks loss ! Thanks !!! It will definitely make things easier.