[ClownNinja]

On the ADC, the xcode tools is available for download but it is in segmented files, 22 of them around 30 MB each. The extension to these files is .bin. How can I take these 22 files and create the installation program?

Thanks

[djohnson]

try getting the single d/l

[JNI]

Originally posted by ClownNinja:
On the ADC, the xcode tools is available for download but it is in segmented files, 22 of them around 30 MB each. The extension to these files is .bin. How can I take these 22 files and create the installation program?

Thanks

The .bin files can be decompressed using Stuffit Expander. Then you wind up with a bunch of files with .dmgpart extensions, and one with just a .dmg extension. You then double click on the .dmg file, and it will find all the other parts automatically (as long as they are in the same folder as the first part) and it will then mount as a virtual volume, from which you can then run the installer. You can also select the .dmg file in the Disk Utility app and burn a CD from it.

[Angus_D]

DiskCopy can cope with .dmg.bin - not sure if Disk Utility can, but from a terminal window you can do hdiutil mount blah.dmg.bin (even if it's a multi-part image).

[suthercd]

I found removing the .bin suffix from the name of the one segment without a sequence number will let either the Finder or Disk Utility join all the segments. Double clicking on the one renamed .dmg file then joins using the Finder on my machine. If you look at the file sizes on the .bin segment before and after Stuffit Expander processes the file, they are identical. You can also burn the CD with the Finder as well as Disk Utility as JNI mentioned.

In the version of Xcode I have, the file to rename is Xcode_1.1.1_7K233.dmg.bin-- edit out the .bin on that one file.

HTH
Craig

[JNI]

Originally posted by suthercd:
I found removing the .bin suffix from the name of the one segment without a sequence number will let either the Finder or Disk Utility join all the segments

I was wondering about that. .bin extensions, at least on Macs circa OS 9, are normally for MacBinary files, which are used for wrapping files that have resource forks, and .dmg files don't have resource forks. It may just be a bad setting on the server, set to always MacBinary all files, or maybe as a safety just in case some odd file may have a resource fork. It might also be done because some browsers used for downloading may not know what to do with .dmg files, and might inadvertently try to treat them as text files (which might cause a CR -> LF translation.) It still seems weird for Apple to do that for definitively OS X only files that they know are binary.

But it doesn't seem to be a problem to let Stuffit Expander do its thing. Whatever - if the resultant image was corrupted, the disk image wouldn't mount, as it is check-summed.

[suthercd]

The MacBinary format was my first thought too which lead me in all kinds of wrong directions.

The .bin suffix started appearing last fall after 10.3's beta builds. After the WWDC in June when a developer's CD was given out with 10.3, that build was made available to Select and Premiere ADC members as a non-segmented download. The result was about a week of clogged pipes from Apple's servers. The next builds released were in segments with the .dmg suffix.

When 10.3 went golden, the segments posted were with the .bin suffix. At that time, I had to use a 10.2 machine to burn the CD's because the beta release of 10.3 was mystified by the .bin suffix. Stuffit Expander had not been upgraded at that point and it was not until the 8.0.1 release that it would properly handle these files in 10.3.

So it seems to me that there is "something" in the Finder being able to archive files in 10.3, the deprecation of Disk Copy, and other changes in 10.3 that are a part of laying the framework for future native network capabilities required the .bin suffix. The pieces to the puzzle are there, but I'm not seeing the whole picture.

Craig

[JNI]

Originally posted by suthercd:
The MacBinary format was my first thought too which lead me in all kinds of wrong directions.
...
When 10.3 went golden, the segments posted were with the .bin suffix. At that time, I had to use a 10.2 machine to burn the CD's because the beta release of 10.3 was mystified by the .bin suffix. Stuffit Expander had not been upgraded at that point and it was not until the 8.0.1 release that it would properly handle these files in 10.3.

So it seems to me that there is "something" in the Finder being able to archive files in 10.3
...

I think all the work is done under the hood essentially with hdiutil. If you do a:

$ hdiutil imageinfo file.dmg.bin

it reports it as MacBinary III encoded, and UDZO format.

In fact, hdiutil will work directly with a .dmg.bin file. If you do:

$ hdiutil mount file.dmg.bin

it mounts the volume fine without using SE first. If you add the -debug option, it shows some conflicting info. At one point it says that it is MacBinary, and then later when it tries to decode the MB segment it says that it doesn't recognize the encoding scheme. It looks like they are doing something wacky with those files, maybe in an attempt at some form of copy-protection?

So it seems to be more a Finder limit in not being able to directly double-click on a .dmg.bin file and have it mount. Very weird indeed.

[suthercd]

Interesting.

Finder scripting has been deprecated in Applescript- replaced by scripting System Events. I'm thinking the Finder is going to go away and a new file system structure is under development.

Time will tell.

Craig

[JNI]

Originally posted by suthercd:
Finder scripting has been deprecated in Applescript- replaced by scripting System Events. I'm thinking the Finder is going to go away and a new file system structure is under development.

What information do you have says that Finder scripting is deprecated? I know that certain operations in the Finder Scripting Suite have moved to System Events and other places, but that is because that stuff shouldn't be exclusively available through the Finder. There is still scriptable stuff in the Finder that belongs there, like for automating the opening of Finder windows, managing Finder selections etc.

For instance, you used to have ask the Finder to get the list of current processes. But the Finder doesn't own the process list, so it is correct to access that info from some other service. Similarly, the Finder doesn't own the filesystem, so doing things to files, like opening, moving, renaming, deleting, mounting volumes, accessing file meta-data and such shouldn't require the Finder.

That wasn't the case in OS 9, because the only way to do certain filesystem and other systemwide operations were through low level Finder APIs. The Finder *had* to be running in OS 9 to do certain things. That is no longer the case in OS X. (note PathFinder). There should be no reason to have to activate the Finder to do system level operations.

The Finder is just an application that is one way to browse the file system, open files and launch apps. It is not the filesystem, and it is not the process manager. There will always be a need for a Finder, and it should be scriptable like any other good application to do the things that it does. E.g. say you want to write a script that opens a couple of tiled windows so that you can easily copy from one location to another. Or a script to arrange icons in its windows (even though the meta data for the icon placement and window sizes should be independently accessible without the Finder.) But the Finder shouldn't need to be running to open files or launch applications.

Even if Apple does implement some new filesystem, or some new filesystem features, like have been rumored, that is all independent of the role of the Finder. Those new features should be accessible outside of the Finder. Of course the Finder should be able to access those services too, along with any other application.