Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MacTron]

the new script is coded to pass commands directly to disk copy 6.5b13

tell application "Disk Copy 6.5b13"

and the old was sending commands to the regular old version of disk copy!!!

tell application "Disk Copy"

no fucking wonder

it may very well work simply by changing this from "disk copy" to "disk copy 6.5b13" in the old script!!!! LOL
if we had renamed disk copy 6.5b13 to "disk copy" and deleted the old.. then it might have just worked just by doing that!

Not at all.
The problem of the old script, even Adam's one, is that don't recognize UDIF images. Even though I've achieved to solve this, but some important functions in to the script failed. I read clearly on Disk Copy AppleScript dictionary that those functions won't work with UDIF. I haven't carefully read the new scripts, but they seems to take a very different procedure...
... so the point are on the script as I've said.

[supernova777]

"tell application Disk Copy" would result in sending the image file to the old "Disk Copy 6.3.3" (jan 1999) version in the utilities folder.. which is what famously has this 2gb limit and cannot checksum an image larger then 2gb

it is within disk copy app that it has the function (under utility dropdown) "calculate disk checksum" and "verify image checksum" the applescript doesnt process the udif image, it merely instructs disk copy to do so.. so even though it was ASR 2.2.4 version, it had this old script from v1.3.8 the old script, which was talking to the wrong version of disk copy... it wasnt using 6.5b13 (jan 2002) disk copy at all!!!

ASR 2.2.1 (2001)
ASR 2.2.3 (2001)

http://support.apple.com/kb/DL1262?viewlocale=en_US (posted Post Date: May 6, 1999)
so this 6.3.3 is from before may of 1999..!

disk copy 6.4 or above is neccessary to read UDIF images...
disk copy 6.4 (Mar 2001)

its amazing that apple never thought to upgrade disk copy version when it was putting out revisions 9.04, 9.1, 9.2??
but this was kept secret for "developers only"

ps. who is adam?

[supernova777]

if we examine the info here..
http://web.archive.org/web/19990427102731/http://til.info.apple.com/techinfo.nsf/artnum/n24601

Mac OS Extended Format: Volume and FIle Limits (dated 2/1/99) ***mac os 8.5
Maximum volume size 2 terabytes
Maximum file size    2 gigabytes
Maximum data fork size    2 gigabytes

vs a later posting:
http://web.archive.org/web/19991117095556/http://til.info.apple.com/techinfo.nsf/artnum/n24601

Mac OS Extended Format: Volume and File Limits (dated 11/16/99) ***mac os 9.0
Maximum number of volumes   21 (2)
Maximum volume size    2 terabytes
Maximum file size   2 terabytes (3)
Maximum data fork size    2 terabytes (4)

it seems that it was around november 1999 that the mac os filesystem was enabled
to have files larger then 2 gb
this 6.3.3 disk copy was programmed in a time that 2gb was the absolute largest file
u could have on a hard drive! the time of mac os 8

[supernova777]

YES. Mac Os 9 can read Dual Layer DVD (commercial and writables).
And may be,Toast 5.2.x can write them, I don't remember for sure if I did it sometime.

i very much hope this is true!
it would be great to have a 4gb bootable restore dvd
and even greater to have the freedom to move to a 8gb bootable restore dvd if the need arises!!

[MacTron]

The info has changed because the first info was erroneous. In 1998 with release of Mac OS 8.1 HFS Plus (Mac OS Extended Format) was also introduced. HFS Plus *NEVER* had this limitations:

Maximum file size    2 gigabytes
Maximum data fork size    2 gigabytes

[supernova777]

mactron.. that info is straight from the tech info library of apple
you are saying its incorrect?

it may very well be that mac os extended filesystem was capable of more, but it took them quite a long time from its introduction, to update all programs + information
to reflect + be compatible with this fact.

disk copy 6.3.3 was probably just updated from an older version that was originally coded for mac os standard filesystem.

the creation date of those facts was : 9/9/98

HFS + was Introduced    January 19, 1998 (Mac OS 8.1)
according to wikipedia http://en.wikipedia.org/wiki/HFS_Plus

thats a pretty big fuck up if its incorrect, for them to write this down incorrectly for the world to read, 9 months after HFS+ was already landed

[MacTron]

mactron.. that info is straight from the tech info library of apple
you are saying its incorrect?

YES.Is incorrect. AFAIK.
...they are human also... LOL

[Syntho]

I restored an OS7.6.1 image onto the drive. It works 100% with the exception of the Digital Performer authorization. Even the Memory thing was fixed, not sure how that happened on OS8.6.

This is gonna save me so much time I can't even begin to explain. I probably spent about 4 months full time over the years just formatting/reinstalling software.

[Protools5LEGuy]

I restored an OS7.6.1 image onto the drive. It works 100% with the exception of the Digital Performer authorization. Even the Memory thing was fixed, not sure how that happened on OS8.6.

This is gonna save me so much time I can't even begin to explain. I probably spent about 4 months full time over the years just formatting/reinstalling software.

Can the Digital Performer authorization be fooled mounting a Toast Image with Toast 5 on OS9? Or we need to write a CD-ROM?

[Syntho]

It's an authorization on your hard drive. I believe it's an invisible file and I could only see it when I used Greg's Browser. Maybe we can use Greg's Browser to copy it and restore it when we need it, but I'd rather just reinstall the damn thing myself.

[Protools5LEGuy]

It's an authorization on your hard drive. I believe it's an invisible file and I could only see it when I used Greg's Browser. Maybe we can use Greg's Browser to copy it and restore it when we need it, but I'd rather just reinstall the damn thing myself.

Some old school user had fried DP and EXS-24 CD-ROMs for quicker re-auth.

I thought that maybe in some cases using Toast 5 with disk images should be quicker than using real CD-ROMs. I saw somewhere that DP needed a REAL CD-ROM to be authored.   

[Protools5LEGuy]

I believe it's an invisible file and I could only see it when I used Greg's Browser. Maybe we can use Greg's Browser to copy it and restore it when we need it, but I'd rather just reinstall the damn thing myself.

http://kaleidoscope.net/greg/browser.html

http://kaleidoscope.net/greg/gregs-browser-27.bin
http://kaleidoscope.net/greg/gregs-browser-27.hqx

[Syntho]

Disk images are always quicker but DP seems to need a burned CD. I bought the original myself so I just use that.

[supernova777]

Disk images are always quicker but DP seems to need a burned CD. I bought the original myself so I just use that.

there is multiple versions of the nocd patch for dp that allow u to use a toast image AFAIK
one for 2.7 and another for 3.0,

but this is offtopic!!!!

[Protools5LEGuy]

there is multiple versions of the nocd patch for dp that allow u to use a toast image AFAIK
one for 2.7 and another for 3.0,

but this is offtopic!!!!

What is not covered thru the magic of clonning with ASR is ONTOPIC. The method to re-authorize quicker ASR clonned images on major DAWs/Samplers/VST(i) should be ontopic too. 

[supernova777]

there is multiple versions of the nocd patch for dp that allow u to use a toast image AFAIK
one for 2.7 and another for 3.0,

but this is offtopic!!!!

What is not covered thru the magic of clonning with ASR is ONTOPIC. The method to re-authorize quicker ASR clonned images on major DAWs/Samplers/VST(i) should be ontopic too. 

yes but like syntho said.. dp authorization is EASY... we are more concerned with not having to enter 256 digit codes to authorize apps that make u type every last fucking character out to auth it
and copying these characters from a pc..
thats the shit we dont ever want to have to do again!!!!!!!

[Syntho]

Why is it that you can't restore the image to a smaller-than-original partition? Has anyone actually tried it?

[MacTron]

Why is it that you can't restore the image to a smaller-than-original partition? Has anyone actually tried it?

No problem with this.

... size of the destination Hard Disk or partition must be equal or bigger than the image file (uncompressed).

Only is important the size of uncompressed image file, not original partition size.

[Syntho]

Oh I see, I misread.

[supernova777]

What is not covered thru the magic of clonning with ASR is ONTOPIC. The method to re-authorize quicker ASR clonned images on major DAWs/Samplers/VST(i) should be ontopic too. 

i meant my comment + that topic of cd patch is offtopic to asr thread..
not you:P