Anyone on the list know what I need to read ancient Apple disks?
An elderly relative has a PPC iMac, the so-called "sunflower mac" http://upload.wikimedia.org/wikipedia/en/0/02/Imac_sunflower2.jpg It eventually died, but the symptoms hinted it wasn't a disk crash. This apparently came with MacO OS 9.2 and a 60.0 GB Ultra ATA/66 hard drive (5400 RPM), so what modern machines can read Mac file formats? I have an Ubunutu-based PVR with an ATA interface that's doing the DVD right now, could I read it from Linux? My old SPARC read Mac SCSI formats... --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
On 2015-01-03 03:55 PM, David Collier-Brown wrote:
what modern machines can read Mac file formats?
Last time I tried this (~2007), a Mac HD was recognized immediately on attaching it to a Linux box. PPC Macs used their own slightly weird partitioning system, but all the HFS filesystems mounted read-only correctly. hfsutils provides a crude shell environment if you ever need to delve into HFS images. Your biggest problem will be the file formats. MacOS 9 was still heavily into its data+resource fork model, so you can often be left with little clue what type of file is on the disk, or be stuck with crazy encoding issues. Mac Applications used to be a mess of very proprietary file formats (Apple Works, I am glaring at you), so let's hope any data you can get off the disk is in something vaguely sensible. And yes, formats like Word and Excel would be considered sensible ones here … Old Macs use just CR for newlines, FYI. cheers, Stewart
I'm after pictures and email, and can probably do a trick with strings to find JPEGs, find and grep to find mailboxes and addressbooks. --dave On 01/03/2015 04:37 PM, Stewart C. Russell wrote:
what modern machines can read Mac file formats? Last time I tried this (~2007), a Mac HD was recognized immediately on attaching it to a Linux box. PPC Macs used their own slightly weird
On 2015-01-03 03:55 PM, David Collier-Brown wrote: partitioning system, but all the HFS filesystems mounted read-only correctly. hfsutils provides a crude shell environment if you ever need to delve into HFS images.
Your biggest problem will be the file formats. MacOS 9 was still heavily into its data+resource fork model, so you can often be left with little clue what type of file is on the disk, or be stuck with crazy encoding issues. Mac Applications used to be a mess of very proprietary file formats (Apple Works, I am glaring at you), so let's hope any data you can get off the disk is in something vaguely sensible. And yes, formats like Word and Excel would be considered sensible ones here …
Old Macs use just CR for newlines, FYI.
cheers, Stewart
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
On Sat, Jan 03, 2015 at 04:50:49PM -0500, David Collier-Brown wrote:
I'm after pictures and email, and can probably do a trick with strings to find JPEGs, find and grep to find mailboxes and addressbooks.
Once you mount the HFS filesystem on linux you can actually get the resource fork too by doing: ls /hfsmnt/filename ls /hfsmnt/filename/rsrc So if you need the resource fork, it can actually be accessed if you know about the special /rsrc option (so essentially pretend the file is a directory with a file inside called rsrc). It won't show in ls that /rsrc exists since afer all the file is a file, not a directory. If a file has no resource fork, then you get an error if you try to access /rsrc. -- Len Sorensen
On 01/03/2015 04:54 PM, Lennart Sorensen wrote:
On Sat, Jan 03, 2015 at 04:50:49PM -0500, David Collier-Brown wrote:
I'm after pictures and email, and can probably do a trick with strings to find JPEGs, find and grep to find mailboxes and addressbooks. Once you mount the HFS filesystem on linux you can actually get the resource fork too by doing:
ls /hfsmnt/filename ls /hfsmnt/filename/rsrc
So if you need the resource fork, it can actually be accessed if you know about the special /rsrc option (so essentially pretend the file is a directory with a file inside called rsrc).
It won't show in ls that /rsrc exists since afer all the file is a file, not a directory.
If a file has no resource fork, then you get an error if you try to access /rsrc.
Excellent, thanks! --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
| From: David Collier-Brown <davec-b@rogers.com> | An elderly relative has a PPC iMac, the so-called "sunflower mac" | http://upload.wikimedia.org/wikipedia/en/0/02/Imac_sunflower2.jpg Nice. A friend ran and Plan9 on one for years. He's the one who ported Plan9 to the Raspberry Pi. | It eventually died, but the symptoms hinted it wasn't a disk crash. What did it die of? I assume that it was terminal (fried mainboard?). | This apparently came with MacO OS 9.2 and a 60.0 GB Ultra ATA/66 hard drive | (5400 RPM), so what modern machines can read Mac file formats? I have an | Ubunutu-based PVR with an ATA interface that's doing the DVD right now, could | I read it from Linux? My old SPARC read Mac SCSI formats... (I'm not sure what "doing the DVD right now" means.) I take it that you don't need to get them up and running again. If you did, I would imagine that the most straight-forward method would be to feed the disk to a modern Mac. They surely have migration tools. I'd try a PATA to USB gizmo because modern Macs don't do PATA. If you need to borrow one, I have one.
On 01/04/2015 01:40 AM, D. Hugh Redelmeier wrote:
| From: David Collier-Brown <davec-b@rogers.com>
| An elderly relative has a PPC iMac, the so-called "sunflower mac" | http://upload.wikimedia.org/wikipedia/en/0/02/Imac_sunflower2.jpg
Nice.
A friend ran and Plan9 on one for years. He's the one who ported Plan9 to the Raspberry Pi.
| It eventually died, but the symptoms hinted it wasn't a disk crash.
What did it die of? I assume that it was terminal (fried mainboard?).
| This apparently came with MacO OS 9.2 and a 60.0 GB Ultra ATA/66 hard drive | (5400 RPM), so what modern machines can read Mac file formats? I have an | Ubunutu-based PVR with an ATA interface that's doing the DVD right now, could | I read it from Linux? My old SPARC read Mac SCSI formats...
(I'm not sure what "doing the DVD right now" means.)
I take it that you don't need to get them up and running again. If you did, I would imagine that the most straight-forward method would be to feed the disk to a modern Mac. They surely have migration tools.
I'd try a PATA to USB gizmo because modern Macs don't do PATA. If you need to borrow one, I have one.
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
Yes, I'd love to borrow it: my PVR has an old parallel interface, but it's in use and I'd have to yank the DVD temporarily to try the Mac disk. --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
On 01/04/2015 07:32 PM, David Collier-Brown wrote:
On 01/04/2015 01:40 AM, D. Hugh Redelmeier wrote:
I'd try a PATA to USB gizmo because modern Macs don't do PATA. If you need to borrow one, I have one. --- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk Yes, I'd love to borrow it: my PVR has an old parallel interface, but it's in use and I'd have to yank the DVD temporarily to try the Mac disk.
Dave, did you receive my private message? I offered you a G4 PowerMac. -- Regards, Clifford Ilkay Dinamis +1 647-778-8696
| From: Clifford Ilkay <clifford_ilkay@dinamis.com> | Dave, did you receive my private message? I offered you a G4 PowerMac. That sounds like the most, uh, powerful option. There probably would be no need to reverse engineer MacOS9 applications' expressive but quirky file structures. BTW: the resource fork / data fork thing in original MacOS seems odd to we UNIX-types who think that a file is a bucket of bytes. But MacOS got a lot of leverage out of that thing. "ResEdit" was a wonder to behold. Essentially: the greatest common denominator for files in MacOS was much higher than in UNIX so generic tools could do much more. What MacOS could do on a machine with 128k of RAM (including the video frame buffer) puts all mainstream GUI systems to shame. Part of this was accomplished by using shared representations, some of which lived in the resource fork. That being said, I wish Linux didn't support forks. They make the file abstraction more complicated with very little benefit or use. The main benefit, as I understand it, is to embrace and extend NTFS.
On Sun, Jan 04, 2015 at 11:12:18PM -0500, D. Hugh Redelmeier wrote:
That sounds like the most, uh, powerful option. There probably would be no need to reverse engineer MacOS9 applications' expressive but quirky file structures.
BTW: the resource fork / data fork thing in original MacOS seems odd to we UNIX-types who think that a file is a bucket of bytes. But MacOS got a lot of leverage out of that thing. "ResEdit" was a wonder to behold. Essentially: the greatest common denominator for files in MacOS was much higher than in UNIX so generic tools could do much more.
What MacOS could do on a machine with 128k of RAM (including the video frame buffer) puts all mainstream GUI systems to shame. Part of this was accomplished by using shared representations, some of which lived in the resource fork.
Also putting the entire OS in ROM saves an awful lot of RAM.
That being said, I wish Linux didn't support forks. They make the file abstraction more complicated with very little benefit or use. The main benefit, as I understand it, is to embrace and extend NTFS.
Linux supports resource forks in filesystems? -- MLen Sorensen
| From: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> | > What MacOS could do on a machine with 128k of RAM (including the video | > frame buffer) puts all mainstream GUI systems to shame. Part of this | > was accomplished by using shared representations, some of which lived | > in the resource fork. | | Also putting the entire OS in ROM saves an awful lot of RAM. Lots of it was not in ROM, especially as the OS advanced and the ROM did not. And the ROM wasn't too large: 64K in original 128k and Fat Macs. (The Atari ST was a lot faster booting because more of its OS was in ROM. On the other hand, the OS didn't advance very quickly or very much. The original Amiga had almost all the OS in RAM because they knew it wasn't yet mature.) | > That being said, I wish Linux didn't support forks. They make the | > file abstraction more complicated with very little benefit or use. | > The main benefit, as I understand it, is to embrace and extend NTFS. | | Linux supports resource forks in filesystems? I was wrong. I was mixing up Extended Attributes (an odd thing) with Alternate Data Streams (a different odd thing). ADS is an NTFS feature to embrace and extend MacOS resource forks. Apparently there is no public API for it except for backing up. Many google hits point out that ADS is a great way to hide things (malware, contraband, porn) on NTFS. Samba and Reiser support ADS to some degree (Samba: optional, Reiser is fading away). I don't know what API they use.
On 2015-01-05 05:49 PM, D. Hugh Redelmeier wrote:
(The Atari ST was a lot faster booting because more of its OS was in ROM. On the other hand, the OS didn't advance very quickly or very much.
The Atari ST was a bit of a disappointment in that it needed a disk to boot. It didn't do much with that disk: just checked to see if it had a boot sector, and if not, started vanilla DR GEM on top of TOS. If it hadn't had that requirement, the OS would've booted instantly. (I still have a tiny soft spot for Atari STs, because of the University of Strathclyde's rather quirky approach to computer acquistion. All of the Mechanical Engineering department ran Atari STs/ATWs* when I was there, so much of my early lab work was done on a crisp B&W Atari display and horrid squodgy keyboard. Hey, it was better than the CompSci group who decided that everyone should have a Sinclair QL [68008, multitasking, weird Microdrive floppy tape drives, hugely buggy] a few years before. I'm sure they are still finding store rooms full of ancient QLs in Glasgow.)
The original Amiga had almost all the OS in RAM because they knew it wasn't yet mature.)
Everything after the A1000 had most of the OS in ROM, though the system got a bit sprawling with AmigaDOS 2.0 and later. The A1000 had a separate RAM page for the Kickstart "WOM" information, since early versions were quite buggy. I was rather fond of the old Tripos-based AmigaDOS, which did pretty nifty multitasking in a system with no MMU. Since I spent so much time writing about Amigas, I sometimes toy with getting some vintage hardware — but then I realise I can emulate it perfectly in my browser … cheers, Stewart *: Yes, we had a couple of Atari Transputer Workstations. They were very cool, but almost impossible to program applications for.
On Tue, Jan 06, 2015 at 08:26:04AM -0500, Stewart C. Russell wrote:
The Atari ST was a bit of a disappointment in that it needed a disk to boot. It didn't do much with that disk: just checked to see if it had a boot sector, and if not, started vanilla DR GEM on top of TOS. If it hadn't had that requirement, the OS would've booted instantly.
(I still have a tiny soft spot for Atari STs, because of the University of Strathclyde's rather quirky approach to computer acquistion. All of the Mechanical Engineering department ran Atari STs/ATWs* when I was there, so much of my early lab work was done on a crisp B&W Atari display and horrid squodgy keyboard. Hey, it was better than the CompSci group who decided that everyone should have a Sinclair QL [68008, multitasking, weird Microdrive floppy tape drives, hugely buggy] a few years before. I'm sure they are still finding store rooms full of ancient QLs in Glasgow.)
Everything after the A1000 had most of the OS in ROM, though the system got a bit sprawling with AmigaDOS 2.0 and later. The A1000 had a separate RAM page for the Kickstart "WOM" information, since early versions were quite buggy. I was rather fond of the old Tripos-based AmigaDOS, which did pretty nifty multitasking in a system with no MMU.
In fact early A3000 machines also used a kickstart image, although what they did was run a modified rom image called 1.4, which would know how to read the HD and was able to read the kickstart image for 2.0 from the HD or a floppy into ram, them use the MMU to remap it and reset from the ram image. Once 2.04 was finished, they usually got the rom replaced by a real one to save the 512KB of ram.
Since I spent so much time writing about Amigas, I sometimes toy with getting some vintage hardware — but then I realise I can emulate it perfectly in my browser …
Nothing quite like the real hardware, and you can do so much crazy stuff with it now that was way to expensive in the past. Emulating the amiga hardware has ben quite hard. -- Len Sorensen
On Mon, Jan 05, 2015 at 05:49:37PM -0500, D. Hugh Redelmeier wrote:
Lots of it was not in ROM, especially as the OS advanced and the ROM did not. And the ROM wasn't too large: 64K in original 128k and Fat Macs.
(The Atari ST was a lot faster booting because more of its OS was in ROM. On the other hand, the OS didn't advance very quickly or very much. The original Amiga had almost all the OS in RAM because they knew it wasn't yet mature.)
Well the original amiga had 256KB ram dedicated to holding the "rom" image, booted from the kickstart disk. It certainly was treated as ROM by the system once booted. By the time I got an A500 they had 256KB rom chips instead, although they hit 512KB later on. That reminds me I should really finish assembling my A500 bits now that I remembered where I had the GVP-A500-HD8+. At the moment I have managed to fit inside an A500: VGA graphics output (1024x768x8bit colour), 68030@25MHz with 32MB ram, dual ROM (1.3 and 3.1). Closing the case got tricky. Now I have to add the GVP SCSI controller with 8MB ram outside. Also has an SD card based dual floppy drive.
I was wrong. I was mixing up Extended Attributes (an odd thing) with Alternate Data Streams (a different odd thing).
Oh OK. I was wondering how I could have missed something so big. :)
ADS is an NTFS feature to embrace and extend MacOS resource forks. Apparently there is no public API for it except for backing up. Many google hits point out that ADS is a great way to hide things (malware, contraband, porn) on NTFS.
NTFS has many awful features.
Samba and Reiser support ADS to some degree (Samba: optional, Reiser is fading away). I don't know what API they use.
samba has to support faking lots of things because of NTFS. -- Len Sorensen
On 01/04/2015 08:01 PM, Clifford Ilkay wrote:
On 01/04/2015 07:32 PM, David Collier-Brown wrote:
On 01/04/2015 01:40 AM, D. Hugh Redelmeier wrote:
I'd try a PATA to USB gizmo because modern Macs don't do PATA. If you need to borrow one, I have one. --- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk Yes, I'd love to borrow it: my PVR has an old parallel interface, but it's in use and I'd have to yank the DVD temporarily to try the Mac disk.
Dave, did you receive my private message? I offered you a G4 PowerMac. -- Regards,
Clifford Ilkay Dinamis
+1 647-778-8696
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk Yes, and thanks, but I have too many machines as it is (;-))
--dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
participants (5)
-
Clifford Ilkay -
D. Hugh Redelmeier -
David Collier-Brown -
Lennart Sorensen -
Stewart C. Russell